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Description 

Technical Field 

5 [0001] The present invention relates to a recording media management system for managing a recording medium 
such as a disk or the like on which variable-length coded data such as MPEG data has been recorded, or specifically 
relates to a method of locating access positions in a recording medium and a managing device of the recording medium. 

Background Art 

10 

[0002] With the recent development of multimedia, demands for recording various types of multimedia data such as 
movie pictures, music, still pictures, onto recording media have increased. Among such recording media, tape media 
such as video tape and audio tape were widely accepted in the past, but in recent years, disk media such as hard 
disks, magnetic disks and the like have become prevalent to store data. 
15 [0003] Tape media are recording media with which recording and reproduction of data is performed sequentially from 
the top of the tape, i.e., by sequential access, so that they are poor in random accessibility. For example, if with a video 
tape, playback from a specified position is wanted, the tape needs to be advanced by fast-forward or rewound by the 
rewind function to adjust the designated position before reproduction. 

[0004] If some index information indicating the target position has been set beforehand, the access can be imple- 
20 mented by simply searching the index but still needs the physical operation of moving the tape to the target position. 
If no index information is provided, it is necessary to locate the target position by implementing fast-forward whilst 
playing back in order to locate the target position, or it is necessary to implement approximate fast-forward adjustment 
using guesswork and final location of the target by playing back in order to obtain access to the target position. In the 
above way, tape media, if they are used, are not suitable to random access because they need physical tape movement. 
25 [0005] In contrast, disk media are excellent in random accessibility, and the access time to an arbitrary location is 
negligible compared to that of tape media. That is, wherever data is on the disk, it is possible to have an access 
instantaneously. 

[0006] As typical utility examples of disk media, MD is known for audio and DVD is known for video, these are widely 
spread because of their random accessibility. 
30 [0007] Now, a case where video data encoded by the MPEG format is recorded onto a disk will be described. For 
recording video data onto a disk or for transmitting it via a transmission line, it is not practical if the video data is directly 
transmitted without being compressed because the amount of data is too bulky. Therefore, it is necessary to compress 
video data to reduce the amount of data by using the MPEG technique or the like. 

[0008] In the MPEG technique, in compressing the amount of data, the variable-length coding technique is used. 

35 Specifically, video data is efficiently reduced in its amount using three types of image compression, namely the intra- 
frame coding picture(l-picture) which is encoded independently using the data within that video frame, the interframe 
forward predictive coding picture(P-picture) which is encoded based on the information of the previous frame and the 
bi-directional predictive coding picture(B-picture) which is encoded based on the previous and subsequent frames. 
[0009] Of these encoded pictures, the compression ratios become higher in the following order, l-picture, P-picture 

40 and B-picture. Therefore, depending on the encoding picture type, the amount of data for one frame of video differs 
from that of another while the amount of data also differs depending on the content of the original video data. For 
example, if video data has less motion, the P-picture and B-picture little differ from the associated l-picture so that the 
data can be compressed markedly efficiently. 

[0010] Illustratively, the amounts of data for individual frames of video data are different as shown in the recording 
45 sequence(on the disk) in Fig. 64, and there is no means by which it is possible to compute the amount of data of each 
frame of MPEG data which has been once encoded, without implementing actual decoding of the MPEG data. 
[0011] In the case where MPEG data which has been variable-length coded is recorded, the amounts of data for 
individual frames are different, therefore, it is impossible to grasp where MPEG data corresponding to each frame has 
been recorded on the disk until the recorded MPEG data is read out from the start of data and decoded sequentially. 
so [0012] In other words, if reproduction is wanted to start from an arbitrary point in the recorded MPEG data, the data 
cannot be played back from such a partway point because the position on the disk where the MPEG data, which 
corresponds to the frame from where the start of playback is wanted, has been recorded cannot be known. 
[0013] Therefore, in order to play back the MPED data recorded on the disk from an arbitrary point, or in order to 
implement special playback using arbitrary frames, it is necessary to obtain management information for managing 
55 the data record positions on the disk corresponding to individual frames. Using this management information, it be- 
comes possible to refer to the recorded location of an tributary frame on the disk. 

[0014] Also, as stated already, MPEG data is efficiently reduced in amount of data by using three types of image 
compression, namely the intraframe coding picture (l-picture), interframe forward predictive coding picture (P-picture) 
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and bi-directional predictive coding picture (B-picture). Since the P-picture and B-picture is generated based on the 
associated l-picture, it is impossible to decode that data only. 

[0015] No problem will occur when MPEG data is decoded and played back serially from the front, but when MPEG 
data is played back from a frame partway in the data or when special playback by picking up arbitrary frames is im- 
5 plemented, the following problem occurs. That is, if the frame from which the start of playback is wanted is a P-picture 
or B-picture, it is impossible to decode the frame without the l-picture and/or P-picture data based on which the frame 
in question has been constructed. 

[0016] To deal with such a situation, the MPEG scheme has a structure called GOP (Group of Pictures) made up of 
a number of frames. This GOP structure is featured by inclusion of at least one l-picture in one GOP. 
10 [0017] Accordingly, if each GOP structure is assumed to be the access unit, the GOP necessarily includes the I- 
picture based on which P-pictures and B-pictures have been constructed, so that decoding of the target frame can be 
assured. 

[0018] In this way, for realizing random access to MPEG data, the access should be made to each GOP structure 
by assuming it to be a unit. For example, even when the start of playback is wanted from a frame partway within a 
15 GOP structure, the control of the playback should be performed such that the whole data of the GOP is decoded first, 
then actual display may be started from the target frame. This produces the same result as if playback were merely 
started from target frame. 

[0019] As described above, in order to start playback from an arbitrary frame within MPEG data, it is necessary to 
at least have positional information on the disk of the GOP that includes target frame, instead of positional information 
20 on the disk of each frame. 

[0020] That is, in the case where positional information of all the frames is given as management information , if the 
data of the frame from which the start of playback is wanted is a B-picture or P-picture, the frame of data from which 
the start of playback is wanted has little meaning because the data cannot be decoded unless the data of the l-picture 
used as the reference. 

25 [0021 ] On the other hand, for a case of special playback such as fast-playback in which only l-pictures and P-pictures 
are reproduced, the positional information of l-pictures and P-pictures on the disk is needed. 

[0022] As one prior art for recording MPEG data onto disk media, there is the read-only type DVD. In DVD, video 
data constituting one GOP and audio data associated with it are multiplexed with a piece of management information 
called a NV (Navigation) pack added to the front of the data. 
30 [0023] Use of NV packs as the information for implementing special playback makes it possible to grasp the positions 
at which the next and previous NV packs have been recorded on the disk, with respect to the site being currently played 
back. 

[0024] Japanese Patent Application Laid-Open Hei 11 No.155130 discloses an example of the address management 
information when MPEG data is recorded into rewritable media. According to this disclosure, the address management 
35 information is configured of time map information including a VOBU (Video Object Unit) map presenting the address 
of each VOBU as one management unit in the MPEG scheme in association with time information, address information 
offering the addresses of the VOBUs to be reproduced at intervals of a fixed time period and identification information 
for identifying each VOBU. 

[0025] Usually, in rewritable recording media, since some MPEG streams may be deleted or moved on the disk, the 
40 management information or the like could be changed disorderedly. In the case where the management information 
is changed disorderedly, the system response will be improved if the management information can be read or written 
by a single access. 

[0026] However, for the aforementioned DVD, management information is constructed on the assumption of ROM 
media, the management information is multiplexed within the MPEG stream every NV pack so it is scattered in pieces 
45 on the disk. Accordingly, to update the management information, it is necessary to make accesses to pieces of the 
management information scattered on the disk, one by one, which is unfeasible. 

[0027] Further, an access to the MPEG stream assumed to be made in the above disclosure described in Japanese 
Patent Application Laid-Open Hei 11 No.155130 is implemented by unitwise- VOBU random access. In this case, the 
number of video frames to be managed by a single VOBU is variable. 
so [0028] In other words, the playback time corresponding to one VOBU is variable, so that when a certain frame is 
tried to be designated by time information, a search of the VOBU including that frame wanted to be reproduced cannot 
be made by a simple calculation. In this case, it is necessary to locate the VOBU by checking the playback period of 
time of each VOBU one by one sequentially from the front VOBU, for example. 

[0029] When the target VOBU is located within a short distance from the front VOBU, it does not take much time for 
55 searching, but when the target is located some distance from the front, it takes much time to search it. To deal with 
this, in this disclosure of Japanese Patent Application Laid-Open Hei 11 No.155130, other than the VOBU map infor- 
mation for managing addresses of all VOBUs and time information, the time map information indicating VOBUs cor- 
responding to the addresses of the VOBUs to be reproduced at intervals of a fixed period of time is used. 
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[0030] That is, for searching the VOBU containing a target video frame, the time map information should be referred 
to first before access to the VOBU information is made. Further, the VOBU map information searched based on the 
time map information does not always hit the VOBU containing the target video frame, VOBU information following the 
searched VOBU information needs to be searched serially until the target VOBU is found. 

5 [0031] As above, since in the prior art, to search the target video frame, a rough search is made first using the time 
map reference information then an exact search is performed using the VOBU information to thereby identify the cor- 
responding address on the disk, the prior art has the problem of such complicated process being needed. 
[0032] Moreover, when post recording such as audio dubbing, superimposition of images, etc., is added, post re- 
cording units (PRUs) for securing areas for this post recording information within the MPEG stream or separately 

10 outside the stream need to be defined in the stream. However, the above described prior art cannot deal with such 
streams. 

[0033] The present invention has been devised in view of what has been discussed above, and it is therefore an 
object of the present invention to provide a recording media management system, including the method of locating 
access positions in a recording medium and managing device of the recording medium, which is able to determine the 
15 address of a target video frame in a simple manner and is adapted to deal with streams having PRUs defined therein. 

Disclosure of Invention 

[0034] In order to solve the above problem the present invention is configured as follows: 
20 [0035] The first aspect of the present invention resides in a data access position locating method for locating access 
positions in a data recording medium in which a data sequence of a continuous recording period in a first data stream 
having video data is managed as a base unit of data, the method comprising the steps of: based on presentation time 
information as to a specified piece of video data and reference time information related to reference position information 
of a target base unit of data, determining a relative time from the reference time information to the presentation time 
25 information; identifying a target subunit of data including the specified piece of video data by operation based on the 
relative time as to the specified piece of video data and a playback time of a subunit of data; and identifying start 
position information of the target subunit of data from relative distance information stored beforehand in a management 
information area, wherein the base unit of data comprises a plurality of subunits of data, each having an identical 
playback time within a single base unit of data, and for each of the base units of data, reference position information 
30 that is the start position information of the base unit of data and relative distance information from the reference position 
information to start position information of each of the subunits of data in the base unit of data are stored beforehand 
in the management information area of a recording medium. 

[0036] According to the first aspect of the present invention, in a multimedia data stream, the positional information 
of an arbitrary frame on the recording medium can be easily obtained without the necessity of complex calculation. 

35 [0037] The second aspect of the present invention resides in the data access position locating method defined in 
the first aspect, wherein the subunit of data is a first unit of data that is an independently editable minimum unit of data. 
[0038] According to the second aspect of the present invention, in a multimedia data stream, the positional information 
of a first unit of data, which is the minimum editable unit for an arbitrary frame, on the recording medium can be easily 
obtained without the necessity of complex calculation. 

40 [0039] The third aspect of the present invention resides in the data access position locating method defined in the 
first aspect, wherein the subunit of data is a second unit of data that is an independently reproducible minimum unit of 
data, and a plurality of the second units of data each having an identical playback time constitute one first unit of data 
that is an independently editable minimum unit of data, and a plurality of the first units of data each having an identical 
playback time within a single base unit of data. 

45 [0040] According to the third aspect of the present invention, in a multimedia data stream, the positional information 
of a second unit of data required for access to an arbitrary frame, on the recording medium can be easily obtained 
without the necessity of complex calculation. 

[0041] Further, since positional information of second units of data which are frequently referenced is given as man- 
agement information, it is possible to refer to management information efficiently without the necessity of calculation 
50 of the positional information. 

[0042] The fourth aspect of the present invention resides in the data access position locating method defined in the 
third aspect further comprising the step of identifying start position information of the first unit of data, using start position 
information of the second units of data. 

[0043] According to the fourth aspect of the present invention, in a multimedia data stream, the positional information 
55 of a second unit of data required for access to an arbitrary frame on the recording medium as well as the positional 
information of a first unit of data, which is the minimum editable unit for an arbitrary frame, on the recording medium 
can be easily obtained without the necessity of complex calculation. 

[0044] The fifth aspect of the present invention resides in the data access position locating method defined in the 
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second through fourth aspects, wherein the data recording medium has in association with the first units of data, audio 
data units for post recording for storing post recording audio data, which differs from the original audio data associated 
with video data and is recordable and reproducible in synchronization with the video data and the management infor- 
mation area has stored beforehand third relative distance information as the start position information of the audio data 
5 unit for post recording for each base unit of data, the method further comprising the step of identifying the start position 
information of the target audio data unit for post recording corresponding to the target first unit of data, based on the 
third relative distance information stored in the management information area. 

[0045] The sixth aspect of the present invention resides in the data access position locating method defined in the 
fifth aspect, wherein the third relative distance information is relative distance information from the reference position 

10 information to the start position information of the audio data unit for post recording. 

[0046] The seventh aspect of the present invention resides in the data access position locating method defined in 
the fifth aspect, wherein the third relative distance information is relative distance information from the start position 
information of the first unit of data to the start position information of the audio data unit for post recording. 
[0047] According to the fifth to seventh aspects of the present invention, the positional information of post recording 

15 audio data on the recording medium, which should be reproduced in synchronization with the predetermined data, can 
be easily obtained in relation with the positional information of the individual units of data without the necessity of 
complex calculation. 

[0048] The eighth aspect of the present invention resides in a data access position locating method for locating 
access position in a data recording medium in which a data sequence of a continuous recording period in a first data 

20 stream having video data is managed as a base unit of data, the method comprising the steps of: based on presentation 
time information as to a specified piece of video data and reference time information related to the reference position 
information of the target base unit of data, determining a relative time from the reference time information to the pres- 
entation time information; identifying a target first unit of data including a specified piece of video data, by operation 
based on the relative time as to the specified piece of video data and the playback time of the first unit of data; and 

25 identifying start position information of the target audio data unit for post recording, corresponding to the target first 
unit of data, from third relative distance information stored beforehand in a management information area, wherein the 
base unit of data comprises a plurality of first units of data, each having an identical playback time within a single base 
unit of data and being an independently editable minimum unit of data; the data recording medium has in association 
with the first units of data, audio data units for post recording for storing post recording audio data, which differs from 

30 original audio data associated with the video data and is recordable and reproducible in synchronization with the video 
data; for each of the base units of data, third relative distance information that is start position information of each of 
the audio data units for post recording is stored beforehand in the management information area of a recording medium. 
[0049] The ninth aspect of the present invention resides in the data access position locating method defined in the 
eighth aspect, wherein the third relative distance information is relative distance information from reference position 

35 information representing the start position information as to the base unit of data to the start position information of the 
audio data unit for post recording. 

[0050] The tenth aspect of the present invention resides in the data access position locating method defined in the 
eighth aspect, wherein the third relative distance information is relative distance information from start position infor- 
mation of the first unit of data to the start position information of the audio data unit for post recording. 
40 [0051] According to the eighth to tenth aspects of the present invention, the positional information of post recording 
audio data on the recording medium, which should be reproduced in synchronization with the predetermined data, can 
be easily obtained without the necessity of complex calculation. 

[0052] The eleventh aspect of the present invention resides in the data access position locating method defined in 
the fifth or eighth aspect, wherein the audio data unit for post recording is provided inside each first unit of data. 
45 [0053] According to the eleventh aspect of the present invention, reading and writing of a plurality of pieces of man- 
agement information can be done in a short period of time. 

[0054] The twelfth aspect of the present invention resides in the data access position locating method defined in the 
fifth or eighth aspect, wherein the audio data unit for post recording is provided outside the base units of data. 
[0055] According to the twelfth aspect of the present invention, since the data area and the management information 
50 area are separated clearly, no file of management information will be created in the data area. Therefore, contiguous 
arrangement of data in the data area can be realized. 

[0056] The thirteenth aspect of the present invention resides in the data access position locating method defined in 
the first or eighth aspect, wherein the management information area is provided inside the data recording medium. 
[0057] According to the thirteenth aspect of the present invention, the data to be reproduced is arranged in proximity 
55 to the management information so that it is possible to realize an increased processing speed. 

[0058] The fourteenth aspect of the present invention resides in the data access position locating method defined 
in the first or eighth aspect, wherein the management information area is provided in a recording medium outside the 
data recording medium. 
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[0059] According to the fourteenth aspect of the present invention, since the management information area is pro- 
vided for a recording medium having a higher access speed than the data recording medium, it is possible to realize 
a faster response. 

[0060] The fifteenth aspect of the present invention resides in a data recording media managing device for managing 

5 a data sequence of a continuous recording period in a first data stream having video data as a base unit of data, 
comprising a controller which manages the data by the steps of: constructing the base unit of data with a plurality of 
first units of data, each being an independently editable minimum unit of data; constructing the first unit of data with a 
plurality of second units of data each being an independently reproducible minimum unit of data; making the first 
playback time for reproducing each of the first units of data identical within a single base unit of data and controlling 

10 the second playback time for reproducing each of the second units of data to be identical within a single first unit of 
data; and managing for each base unit of data, reference position information as the start position information of the 
base unit of data and first relative distance information from the reference position information to start position infor- 
mation of a first unit of data in the base unit of data, in a manner that allows them to be written in, or read out from, 
the data recording medium or the management information area arranged somewhere with respect to holder of the 

15 data recording medium. 

[0061 ] The sixteenth aspect of the present invention resides in a data recording media managing device for managing 
a data sequence of a continuous recordinc period in a first data stream having video data as a base unit of data, 
comprising a controller which manages the data by the steps of: constructing the base unit of data with a plurality of 
first units of data, each being an independently editable minimum unit of data; constructing the first unit of data with a 

20 plurality of second units of data each being an independently reproducible minimum unit of data; making the first 
playback time for reproducing each of the first units of data identical within a single base unit of data and controlling 
the second playback time for reproducing eact of the second units of data to be identical within a single first unit of 
data; and managing for each base unit of data, the reference position information as the start position information of 
the base unit of data and second relative distance information from the reference position information to the start 

25 position information of a predetermined second unit of data in the base unit of data, in a manner that allows them to 
be written in, or read out from, the data recording medium or the management information area provided for the holder 
of the data recording medium. 

[0062] According to the fifteenth and sixteenth aspects of the present invention, the data recording media managing 
device, in a data recording medium in which the base unit of data is divided into the first units of data and the second 
30 units of data based on playback time, manages the reference position information and the first relative distance infor- 
mation in the management information area. Therefore, the managing device, using time information as the key infor- 
mation, can convert it into positional information by a simple process, thus making it possible to have easy access to 
an arbitrary frame in the unit of data. 

[0063] Further, even when a plurality of pieces of management information should be read or written, it is possible 
35 to have it done in a short period of time. Since the data area and the management information area are separated 
clearly, no file of management information will be created in the data area. Therefore, contiguous arrangement of data 
in the data area can be realized. 

[0064] The seventeenth aspect of the present invention resides in the data recording media managing device defined 
in the fifteenth or sixteenth aspect, wherein the controller constructs in the data recording medium an audio data unit 

40 for post recording for storing post recording audio data, which differs from the original audio data associated with the 
video data and is recordable and reproducible in synchronization with the video data, and manages third relative dis- 
tance information from the reference position information to the start position information of the audio data unit for post 
recording, in association with each of the first units of data, in a manner that allows it to be written in or read out from 
the management information area. 

45 [0065] According to the seventeenth aspect of the present invention, since the positional information of post recording 
audio data can be also obtained by a simple process, using time information as the key information, post recording 
audio data can be reproduced efficiently. 

[0066] The eighteenth aspect of the present invention resides in the data recording media managing device defined 
in the seventeenth aspect, wherein the audio data unit for post recording is provided inside the first unit of data. 

50 [0067] According to the eighteenth aspect of the present invention, the data to be reproduced is arranged in proximity 
to the management information so that it is possible to realize an increased processing speed. 
[0068] The nineteenth aspect of the present invention resides in the data recording media managing device defined 
in the seventeenth aspect, wherein the audio data unit for post recording is created outside the base units of data. 
[0069] According to the nineteenth aspect of the present invention, this configuration will not make the stream com- 

55 position complex, so makes it easy to access the other units of data. 

[0070] The twentieth aspect of the present invention resides in the data recording media managing device defined 
in the fifteenth or sixteenth aspect, wherein the controller manages offset information that gives an offset value for 
positional information in a manner that allows it to be written in or read out from the management information area. 
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[0071] According to the twentieth aspect of the present invention, since when some front part of the multimedia 
stream has been deleted, the positional information of the deleted data is recorded as the management information, 
i.e., the offset value, this makes it unnecessary to renew each piece of positional information in various pieces of 
management information, thus making it possible to save the editing job. 
5 [0072] The twenty-first aspect of the present invention resides in the data recording media managing device having 
the fifth aspect, wherein the controller is able to compute a data playback rate of the first unit of data, based on the 
first relative distance information and the first playback time. 

[0073] According to the twenty-first aspect of the present invention, since the playback rate of video data in the first 
unit of data can be determined by calculation, it is possible to grasp the playback rate of data beforehand, without 
10 reproducing the video data. 

[0074] The twenty-second aspect of the present invention resides in the data recording media managing device 
defined in the sixteenth aspect, wherein the controller is able to compute a data playback rate of the second unit of 
data, based on the second relative distance information and the second playback time. 

[0075] According to the twenty-second aspect of the present invention, since the playback rate of video data in the 
15 second unit of data can be determined by calculation, it is possible to grasp the playback rate of data beforehand, 
without reproducing the video data. 

[0076] The twenty-third aspect of the present invention resides in the data recording media managing device defined 
in the fifteenth or sixteenth aspect, wherein the positional information is given in a relative address representation 
which disregard any divided arrangement on the recording medium. 
20 [0077] According to the twenty-third aspect of the present invention, since start addresses are given in a relative 
address representation, which disregards the divided arrangement of the stream on the recording medium, the data 
amount of the data managed by the first or second unit can be known from the relationship between one start address 
and the next. 

[0078] The twenty-fourth of the present invention resides in the data recording media managing device defined in 
25 the seventeenth aspect, wherein the controller manages post recording presence/absence information that indicates 
whether the post recording audio data to be reproduced in synchronization has been stored in the audio data unit for 
post recording in a manner that allows it to be written in or read out from the management information area. 
[0079] According to the twenty-fourth aspect of the present invention, since upon data reproduction it is possible to 
grasp whether post recording audio data should be read out in advance, this makes the process more efficient. 
30 [0080] The twenty-fifth of the present invention resides in the data recording media managing device defined in the 
seventeenth, wherein the controller manages post recording presence/absence information that indicates whether the 
post recording audio data to be reproduced in synchronization with the first unit of data has been stored in the audio 
data unit for post recording in a manner that allows it to be written in or read out from the management information area. 
[0081] According to the twenty-fifth aspect of the present invention, since upon data reproduction it is possible to 
35 grasp whether post recording audio data should be read out in advance for every first unit, this makes the process 
more efficient. 

[0082] The twenty-sixth of the present invention resides in the data recording media managing device defined in the 
seventeenth aspect, wherein the controller manages post recording presence/absence information that indicates 
whether the post recording audio data to be reproduced in synchronization with the second unit of data has been stored 
40 in the audio data unit for post recording in a manner that allows it to be written in or read out from the management 
information area. 

[0083] According to the twenty-sixth aspect of the present invention, since upon data reproduction it is possible to 
grasp whether post recording audio data should be read out in advance for every second unit, this makes the process 
more efficient. 

45 [0084] The twenty-seventh of the present invention resides in the data recording media managing device defined in 
the fourteenth or fifteenth aspect, wherein the controller manages data contiguousness information that indicates 
whether the data corresponding to the first unit of data and the data corresponding to the subsequent first unit of data, 
which are continuous temporally, are arranged logically and contiguously on the recording medium, in a manner that 
allows it to be written in or read out from the management information area. 

50 [0085] According to the twenty-seventh aspect of the present invention, since it is possible to grasp whether the 
observed first unit is arranged logically and contiguously to the previous first unit, on the recording medium, without 
referring to the logical filesystem information, this makes the process more efficient. 

[0086] The twenty-eighth of the present invention resides in the data recording media managing device defined in 
fifteenth or sixteenth aspect, wherein the controller manages information that indicates whether or not a GOP at the 
55 front of the second unit of data is a closed GOP, in a manner that allows it to be written in or read out from the man- 
agement information area. 

[0087] According to the twenty-eighth aspect of the present invention, before reproduction of a second unit of data, 
it is possible to grasp whether it is necessary to access to the previous second unit in order to perform correct repro- 
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duction of the frames in the GOP within the second unit of data. 

[0088] The twenty-ninth of the present invention resides in the data recording media managing device defined in the 
fifteenth or sixteenth aspect, wherein the controller manages video frame information that indicates the number of 
video frames of MPEG data to be managed in the second unit of data, in a manner that allows it to be written in or 
5 read out from the management information area. 

[0089] According to the twenty-ninth aspect of the present invention, each of the second units of data is allowed to 
manage not a fixed number of frames but an arbitrary number of frames. 

[0090] The thirtieth of the present invention resides in the data recording media managing device defined in the 
fifteenth or sixteenth aspect, wherein the controller manages a video frame of MPEG data to be managed in a second 
10 unit of data by allowing end position information that represents an end address of a reference picture on the recording 
medium to be written in or read out from the management information area. 

[0091] According to the thirtieth aspect of the present invention, since the amount of data to be read from the start 
of the second unit of data to the target reference picture can be grasped in advance, this facilitates achievement of 
special playback. 

15 [0092] The thirty-first aspect of the present invention resides in the data recording media managing device defined 
in the fifteenth or sixteenth aspect, wherein the controller manages reference picture start position information that 
represents a start address on the disk of a reference picture for the video frame of MPEG data to be managed in a 
second unit of data and reference picture end position information that represents an end address thereof, in a manner 
that allows them to be written in or read out from the management information area. 

20 [0093] According to the thirty-first aspect of the present invention, when a recording medium having a high enough 
access performance is used, the target reference pictures can be read selectively based on the positional information 
from which data should be read. This feature facilitates achievement of special playback. 

[0094] The thirty-second aspect of the present invention resides in the data recording media managing device defined 
in the fifteen or sixteen , wherein the controller manages a video frame of MPEG data to be managed in the second 
25 unit of data by allowing start position information that represents a start address of a reference picture on the recording 
medium to be written in or read out from the management information area. 

[0095] According to the thirty-second aspect of the present invention, since the start addresses of all the frames are 
managed, it is possible to easily determine the amount of data of each frame from the difference from the start address 
to the next frame and to selectively read out the data of an arbitrary frame when a recording medium having a high 

30 enough access performance is used. Therefore, these features facilitate achievement of special playback. 

[0096] The thirty-third aspect of the present invention resides in a data recording media managing device for man- 
aging a data sequence of a continuous recording period in a first data stream having video data as a base of data, 
wherein the base unit of data comprises a plurality of subunits of data, the device comprising a controller which manages 
each base unit of data in a manner that reference position information as start position information of the base unit of 

35 data, relative distance information of each of individual subunits of data in the base unit of data from the base position 
information to the start position information of the individual subunit of data and post recording presence/absence 
information that indicates whether post recording audio data to be reproduced in synchronization has been stored in 
a post recording audio data unit, are allowed to be written in or read out from, the data recording medium, or the 
management information area arranged somewhere with respect to an indicator of the data recording medium. 

40 [0097] According to the thirty-third aspect of the present invention, since upon data reproduction it is possible to 
grasp whether post recording audio data should be read in advance, this makes the process more efficient. 
[0098] The recording media management system according to the thirty-fourth aspect of the present invention is a 
management system for a recording medium recorded with a multimedia data stream wherein in a first data (original 
data) made up of video and sound, an amount of data for a predetermined playback period is managed as a first unit 

45 (EU), an individually reproducible minimum unit of data in the first unit (EU) is managed as a second unit (VU), each 
of the first units (EUs) is adapted to have an equal period of playback time to others, and each of the second units 
(VUs) is adapted to have an equal period of playback time to others. In this management system, the positional infor- 
mation of the second unit (VU) on the recording medium is held as management information for every second unit, so 
that the positional information of the first unit (EU) on the recording medium is calculated based on the positional 

50 information of the second unit (VU) on the recording medium. 

[0099] According to the thirty-fourth aspect of the present invention, in a multimedia data stream, the positional 
information of the second unit on the recording medium needed to have access to an arbitrary frame and the positional 
information of the first unit on the recording medium as a minimum unit of destructive edit can be easily obtained without 
the necessity of complex calculation. 

55 [0100] Further, since the positional information of a second unit which is referenced frequently is provided as man- 
agement information, it is possible to refer to management information efficiently without the necessity of calculation 
of the positional information. 

[0101] The recording media management system according to the thirty-fifth aspect of the present invention is a 
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management system for a recording medium recorded with a multimedia data stream wherein in a first data (original 
data) made up of video and sound, an amount of data for a predetermined playback period and second data (post 
recording data) to be reproduced in synchronization with the above data are managed as a first unit (EU), an individually 
reproducible minimum unit of data in the first unit (EU) is managed as a second unit (VU), each of the first units (EUs) 

5 is adapted to have an equal period of playback time to others, and each of the second units (VUs) is adapted to have 
an equal period of playback time to others. In this management system, the positional information of the second data 
(post recording data) on the recording medium is held as management information for every piece of second data while 
the positional information of the second unit (VU) on the recording medium is held as management information for 
every second unit, so that the positional information of the first unit (EU) on the recording medium is calculated based 

10 on the positional information of the second data (post recording data) on the recording medium and the positional 
information of the second unit (VU) on the recording medium. 

[0102] According to the thirty-fifth aspect of the present invention, in a multimedia data stream, the positional infor- 
mation of a second unit on the recording medium required for access to an arbitrary frame, the positional information 
of second data on the recording medium, to be reproduced in synchronization with the predetermined data, and the 
15 positional information of the first unit as the minimum unit for destructive edit on the recording medium can be easily 
obtained without the necessity of complex calculation. 

[0103] Further, since the positional information of a second unit which is referenced frequently and the positional 
information of second data are provided as management information, it is possible to refer to management information 
efficiently without the necessity of calculation of the positional information. 

20 [0104] The recording media management system according to the thirty-sixth aspect of the present invention is a 
management system for a recording medium recorded with a multimedia data stream wherein in a first data (original 
data) made up of video and sound, an amount of data for a predetermined playback period is managed as a first unit 
(EU), an individually reproducible minimum unit of data in the first unit (EU) is managed as a second unit (VU), each 
of the first units (EUs) is adapted to have an equal period of playback time to others, and each of the second units 

25 (VUs) is adapted to have an equal period of playback time to others. In this management system, the positional infor- 
mation of the first unit (EU) on the recording medium is held as management information for every first unit and the 
positional information of the second unit (VU) on the recording medium is held as management information for every 
second unit. 

[0105] According to the thirty-sixth aspect of the present invention, in a multimedia data stream, the positional infor- 
30 mation of a second unit on the recording medium required for access to an arbitrary frame and the positional information 
of the first unit as the minimum unit for destructive edit can be easily obtained without the necessity of complex calcu- 
lation. 

[0106] The recording media management system according to the thirty-seventh aspect of the present invention is 
a management system for a recording medium recorded with a multimedia data stream wherein in a first data (original 

35 data) made up of video and sound, an amount of data for a predetermined playback period and second data (post 
recording data) to be reproduced in synchronization with the above data are managed as a first unit (EU), an individually 
reproducible minimum unit of data in the first unit (EU) is managed as a second unit (VU), each of the first units (EUs) 
is adapted to have an equal period of playback time to others, and each of the second units (VUs) is adapted to have 
an equal period of playback time to others. In this management system, the positional information of the first unit (EU) 

40 on the recording medium and the distance information from the starting position of each first unit (EU) on the recording 
medium to the starting position of the second data (post recording data) on the recording medium are held as man- 
agement information for every first unit while the positional information of the second unit (VU) on the recording medium 
is held as management information for every second unit. 

[0107] According to the thirty-seventh aspect of the present invention, in a multimedia data stream, the positional 
45 information of a second unit on the recording medium required for access to an arbitrary frame, the positional information 
of second data on the recording medium, to be reproduced in synchronization with the predetermined data, and the 
positional information ofthefirstunit as the minimum unit for destructive edit can be easily obtained without the necessity 
of complex calculation. 

[0108] The recording media management system according to the thirty-eighth aspect of the present invention is a 
50 management system for a recording medium recorded with a multimedia data stream wherein in a first data (original 
data) made up of video and sound, an amount of data for a predetermined playback period and second data (post 
recording data) to be reproduced in synchronization with the above data are managed as a first unit (EU), an individually 
reproducible minimum unit of data in the first unit (EU) is managed as a second unit (VU), each of the first units (EUs) 
is adapted to have an equal period of playback time to others, and each of the second units (VUs) is adapted to have 
55 an equal period of playback time to others. In this management system, the positional information of the second unit 
(VU) on the recording medium and the distance information from the starting position of each first unit (EU) on the 
recording medium to the starting position of the second data (post recording data) on the recording medium are held 
as management information for every second unit while the positional information of the first unit (EU) on the recording 
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medium is calculated based on the positional information of the second unit (VU) on the recording medium. 
[0109] According to the thirty-eighth aspect of the present invention, in a multimedia data stream, the positional 
information of a second unit on the recording medium required for access to an arbitrary frame, the positional information 
of second data on the recording medium, to be reproduced in synchronization with the predetermined data, and the 
5 positional information of thef irst unit as the minimum unitfor destructive edit can be easily obtained without the necessity 
of complex calculation. 

[01 1 0] Further, since only the positional information of the second unit is held as management information , manage- 
ment can be performed with subminimal information. 

[0111] The thirty-ninth aspect of the present invention resides in the recording media management system written 
10 in the above thirty-fourth to thirty-eighth aspects, wherein the management information includes a piece of information 
that gives an offset value for positional information. 

[0112] According to the thirty-ninth aspect of the present invention, since when some front part of the multimedia 
stream has been deleted, the number of blocks of the deleted data is recorded into the management information as 
the offset value, this makes it unnecessary to renew each piece of positional information in various pieces of manage- 
rs ment information, thus making it possible to save the editing job. 

[0113] The fortieth aspect of the present invention resides in the recording media management systems defined in 
the inventions of the above thirty-fourth to thirty-eighth aspects which include the management information indicating 
the playback time of the video data managed by each of the first units. 

[0114] According to the fortieth invention, use of the management information indicating the playback time of the 
20 video data within each first unit makes it possible to identify the first unit to which an arbitrary frame belongs by the 
time stamp information of the frame. 

[0115] The forty-first aspect of the present invention resides in the recording media management system defined in 
the above fortieth aspect, wherein the playback rate of video data in a first unit is calculated based on the positional 
information of the first unit on the recording medium and the playback time of the video data managed by the first unit. 
25 [0116] According to the forty -first aspect of the present invention, since the playback rate of video data in a first unit 
of data can be determined by calculation, it is possible to grasp the playback rate of data beforehand, without repro- 
ducing the video data. 

[01 1 7] The forty-second aspect of the present invention resides in the recording media management systems defined 
in the above thirty-fourth to thirty-eighth aspects which include the management information indicating the playback 
30 time of the video data managed by the second unit. 

[0118] According to the forty-second of the present invention, use of the management information indicating the 
playback time of the video data within the second unit makes it possible to identify the second unit to which an arbitrary 
frame belongs by the time stamp information of the frame. 

[0119] The forty-third aspect of the present invention resides in the recording media management system defined 
35 in the above forty-second aspect, wherein the playback rate of video data in a second unit is calculated based on the 
positional information of the second unit on the recording medium and the playback time of the video data managed 
by the second unit. 

[0120] According to the forty-third aspect of the present invention, since the playback rate of video data in a second 
unit can be determined by calculation, it is possible to grasp the playback rate of data beforehand, without reproducing 
40 the video data. 

[0121] The forty-fourth aspect of the present invention resides in the recording media management systems defined 
in the above thirty-fourth to thirty-eighth aspects, wherein the management information includes as positional informa- 
tion of a unit or data, a piece of information indicating the start address of the unit or data on the recording medium. 
[0122] According to the forty-fourth aspect of the present invention, since the start address of each piece of data on 
45 the recording medium is used as positional information, it is possible to obtain the start position of access to the data 
managed by various pieces of management information. 

[0123] The forty-fifth aspect of the present invention resides in the recording media management system defined in 
the above forty-fourth aspect, wherein the start address on the recording medium is represented by the relative address 
which disregards any divided arrangement of the stream on the recording medium. 

50 [0124] According to the forty-fifth aspect of the present invention, since the start address is given by a relative address 
representation, which disregards the divided arrangement of the stream on the recording medium, the data amount of 
the data managed by the first or second unit can be known from the relationship between one start address and the next. 
[0125] The forty-sixth aspect of the present invention resides in the recording media management systems defined 
in the above thirty-fourth to thirty-eighth aspects, wherein the management information for each of the second units 

55 includes the information representing whether the second data contains the data to be reproduced in synchronization 
with the second unit. 

[0126] According to the forty-sixth aspect of the present invention, it is possible to grasp for each of the second units, 
whether the second data needs to be read in advance upon reproduction of data, based on the management information 
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representing whether the second data contains data to be reproduced in synchronization with the second unit. 
[0127] The forty-seventh aspect of the present invention resides in the recording media management systems de- 
fined in the above thirty-fifth to thirty -seventh aspects, wherein the management information for each of the first units 
orthe management information forthe second data includes information representing whether the second data contains 

5 the data to be reproduced in synchronization with the first unit. 

[0128] According to the forty-seventh aspect of the present invention, it is possible to grasp for each of the first units, 
whether the second data needs to be read in advance upon reproduction of data, based on the management information 
representing whether the second data contains data to be reproduced in synchronization with the first unit. 
[0129] The forty-eighth aspect of the present invention resides in the recording media management systems defined 

10 in the above thirty-fourth to thirty-eighth aspects, wherein the management information for each of the second units or 
the management information for each of the first units includes information indicating whether the data corresponding 
to the first units temporally continuous are arranged logically and contiguously on the recording medium. 
[0130] According to the forty-eighth aspect of the present invention, it is possible to grasp whether the observed first 
unit is arranged logically and contiguously to the previous first unit, on the recording medium, without referring to the 

15 logical filesystem information. 

[0131] The forty-ninth aspect of the present invention resides in the recording media management systems defined 
in the above thirty-fourth to thirty-eighth aspects, wherein the management information for each of the second units 
includes information indicating whether or not the GOP at the front of the second unit is a closed GOP. 
[0132] According to the forty-ninth aspect of the present invention, before reproduction of a second unit, it is possible 

20 to grasp whether it is necessary to access to the previous second unit in order to perform correct reproduction of the 
frames in the GOP in the second unit. 

[0133] The fiftieth aspect of the present invention resides in the recording media management systems defined in 
the above thirty-fourth to thirty-eighth aspects, wherein the management information for each of the second units in- 
cludes information indicating the number of the positional information of video frames of MPEG data to be managed 
25 in the second unit. 

[0134] According to the fiftieth aspect of the present invention, each of the second units is allowed to manage not a 
fixed number of frames but an arbitrary number of frames. 

[0135] The fifty-first aspect of the present invention resides in the recording media management systems defined in 
the above thirty-fourth to thirty-eighth aspects, wherein the management information for each of the second units in- 
30 eludes information indicating the end addresses of reference pictures on the recording medium, as the positional in- 
formation of the video frames of MPEG data to be managed in the second unit. 

[0136] According to the fifty-first aspect of the present invention, since the amount of data to be read from the start 
of the second unit to the target reference picture can be grasped in advance, this facilitates achievement of special 
playback. 

35 [0137] The fifty-second aspect of the present invention resides in the recording media management systems defined 
in the above thirty-fourth to thirty-eighth aspects, wherein the management information for each of the second units 
includes information indicating the start addresses end addresses of reference pictures on the recording medium, as 
the positional information of the video frames of MPEG data to be managed in the second unit. 
[0138] According to the fifty-second aspect of the present invention, when a recording medium having a high enough 

40 access performance is used, the target reference pictures can be read selectively based on the positional information 
from which data should be read. Therefore, this facilitates achievement of special playback. 

[0139] The fifty-third aspect of the present invention resides in the recording media management systems defined 
in the above thirty-fourth to thirty-eighth aspects, wherein the management information for each of the second units 
includes information indicating the start addresses of all the pictures therewithin on the recording medium, as the 

45 positional information of all the video frames of MPEG data in the second unit. 

[0140] According to the fifty-third aspect of the present invention, since the start addresses of all the frames are 
managed, it is possible to easily determine the amount of data of each frame, based on the difference from the start 
address to the start address of the next frame and to selectively read out the data of an arbitrary frame when a recording 
medium having a high enough access performance is used. Therefore, these features facilitate achievement of special 

50 playback. 

[0141] The fifty-fourth aspect of the present invention resides in the recording media management systems defined 
in the above thirty-fourth to fifty-third aspects, wherein the management information is recorded in a predetermined 
management area on the recording medium. 

[0142] According to the fifty-fourth aspect of the present invention, it is possible to read and write a plurality of pieces 
55 of management information in a short period of time. Further, since the data area and the management information 
area are separated clearly, no file of management information will be created in the data area. Therefore, contiguous 
arrangement of data in the data area can be realized. 
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Brief Description of Drawings 
[0143] 

5 Fig. 1 is an illustrative view showing an MPEG stream composition used in the first embodiment of a recording 

media management system of the present invention; 

Fig. 2 is an illustrative view showing the relationship of blocks in an MPEG stream used in the first embodiment of 
a recording media management system of the present invention; 

Fig. 3 is an illustrative view showing the start address of a VU offered by an Address LUT in order to have access 
10 to a target frame, in the first embodiment of a recording media management system of the present invention; 

Fig. 4 is an illustrative view showing an EUS managed as a file by a logical filesystem in the first embodiment of a 
recording media management system of the present invention; 

Fig. 5 is an illustrative view showing the content of management information 'EUS Information 1 in the first embod- 
iment of a recording media management system of the present invention; 
15 Fig. 6 is an illustrative view showing the content of management information 'Program Information' in the first em- 

bodiment of a recording media management system of the present invention; 

Fig. 7 is an illustrative view showing the content of management information 'EUS Stream Information' in the first 
embodiment of a recording media management system of the present invention; 

Fig. 8 is an illustrative view showing the relationship between EUS Information and EUSs in the first embodiment 
20 of a recording media management system of the present invention; 

Fig. 9 is an illustrative view showing a PRU layout when no EU Header is present in the MPEG stream, in the first 
example of the recording media management system of the present invention; 

Fig. 1 0 is an illustrative view showing a PRU layout when an EU Header is present in the MPEG stream, in the first 
example of the recording media management system of the present invention; 
25 Fig. 11 is an illustrative view showing the scheme of an Address LUT in the first example of the recording media 

management system of the present invention; 

Fig. 12 is an illustrative view showing the content of an Address LUT in the first example of the recording media 
management system of the present invention; 

Fig. 13 is an illustrative view showing the content of PRU Information in the first example of the recording media 
30 management system of the present invention; 

Fig. 1 4 is an illustrative view showing the content of PRU Status in the first example of the recording media man- 
agement system of the present invention; 

Fig. 15 is an illustrative view showing the content of VU Information in the first example of the recording media 
management system of the present invention; 
35 Fig. 1 6 is an illustrative view showing the content of VU Status in the first example of the recording media man- 

agement system of the present invention; 

Fig. 1 7 is an illustrative view showing a method of calculating the start address of a VU in the first example of the 
recording media management system of the present invention; 

Fig. 1 8 is an illustrative view showing a method of calculating the start address of a PRU in the first example of the 
40 recording media management system of the present invention; 

Fig. 19 is an illustrative view showing a PRU layout when no EU Header is present in the MPEG stream, in the 
second example of the recording media management system of the present invention; 

Fig. 20 is an illustrative view showing a PRU arrangement when an EU Header is present in the MPEG stream, in 
the second example of the recording media management system of the present invention; 
45 Fig. 21 is an illustrative view showing the scheme of an Address LUT in the second example of the recording media 

management system of the present invention; 

Fig. 22 is an illustrative view showing the content of an Address LUT in the second example of the recording media 
management system of the present invention; 

Fig. 23 is an illustrative view showing the content of EU Information in the second example of the recording media 
50 management system of the present invention; 

Fig. 24 is an illustrative view showing the content of EU Status in the second example of the recording media 
management system of the present invention; 

Fig. 25 is an illustrative view showing the content of VU Information in the second example of the recording media 
management system of the present invention; 
55 Fig. 26 is an illustrative view showing the content of VU Status in the second example of the recording media 

management system of the present invention; 

Fig. 27 is an illustrative view showing a method of calculating the start address of a VU in the second example of 
the recording media management system of the present invention; 
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Fig. 28 is an illustrative view showing a method of calculating the start address of an EU in the second example of 
the recording media management system of the present invention; 

Fig. 29 is an illustrative view showing a method of calculating the start address of a PRU in the second example 
of the recording media management system of the present invention; 
5 Fig. 30 is an illustrative view showing a PRU layout when no EU Header is present in the MPEG stream, in the 

third example of the recording media management system of the present invention; 

Fig. 31 is an illustrative view showing a PRU layout when an EU Header is present in the MPEG stream, in the 
third example of the recording media management system of the present invention; 

Fig. 32 is an illustrative view showing the scheme of an Address LUT in the third example of the recording media 
10 management system of the present invention; 

Fig. 33 is an illustrative view showing the content of an Address LUT in the third example of the recording media 
management system of the present invention; 

Fig. 34 is an illustrative view showing the content of VU Information in the third example of the recording media 
management system of the present invention; 
15 Fig. 35 is an illustrative view showing the content of VU Status in the third example of the recording media man- 

agement system of the present invention; 

Fig. 36 is an illustrative view showing a method of calculating the start address of a VU in the third example of the 
recording media management system of the present invention; 

Fig. 37 is an illustrative view showing a method(method 1) of calculating the start address of an EU in the third 
20 example of the recording media management system of the present invention; 

Fig. 38 is an illustrative view showing a method(method 2) of calculating the start address of an EU in the third 
example of the recording media management system of the present invention; 

Fig. 39 is an illustrative view showing a method of calculating the start address of a PRU in the third example of 
the recording media management system of the present invention; 
25 Fig. 40 is an illustrative view showing relative address information in the Address LUT in the first embodiment of a 

recording media management system of the present invention; 

Fig. 41 is an illustrative view showing Address Offset information in the first embodiment of a recording media 
management system of the present invention; 

Fig. 42 is an illustrative view showing End RLBN of IP Pictures in the first embodiment of a recording media man- 
30 agement system of the present invention; 

Fig. 43 is an illustrative view showing the system configuration in the first embodiment of a recording media man- 
agement system of the present invention; 

Fig. 44 is an illustrative view showing a disk area having a management information area therein in the first em- 
bodiment of a recording media management system of the present invention; 
35 Fig. 45 is an illustrative view showing a case where management information is disposed at the front of each EUS 

in the first embodiment of a recording media management system of the present invention; 
Fig. 46 is an illustrative view showing a case where management information is multiplexed into the stream by 
embedding it in EU Headers, in the first embodiment of a recording media management system of the present 
invention; 

40 Fig. 47 is an illustrative view showing a case where management information is stored in a non-volatile semicon- 

ductor memory provided for the disk cartridge, in the first embodiment of a recording media management system 
of the present invention; 

Fig. 48 is an illustrative view showing the relationship of blocks in an MPEG stream used in the second embodiment 
of a recording media management system of the present invention; 
45 Fig. 49 is an illustrative view showing the relationship of blocks in an MPEG stream used in the second embodiment 

of a recording media management system of the present invention; 

Fig. 50 is an illustrative view showing EUSs and PRSs managed as files by a logical filesystem in the second 
embodiment of a recording media management system of the present invention; 

Fig. 51 is an illustrative view showing the content of management information 'EUS Information 1 in the second 
50 embodiment of a recording media management system of the present invention; 

Fig. 52 is an illustrative view showing the scheme of an Address LUT in the second embodiment of a recording 
media management system of the present invention; 

Fig. 53 is an illustrative view showing the content of an Address LUT in the second embodiment of a recording 
media management system of the present invention; 
55 Fig. 54 is an illustrative view showing the content of PRU Information in the second embodiment of a recording 

media management system of the present invention; 

Fig.55 is an illustrative view showing the content of PRU Status in the second embodiment of a recording media 
management system of the present invention; 
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Fig. 56 is an illustrative view showing the content of VU Information in the second embodiment of a recording media 
management system of the present invention; 

Fig. 57 is an illustrative view showing the content of VU Status in the second embodiment of a recording media 
management system of the present invention; 
5 Fig. 58 is an illustrative view showing a method of calculating the start address of a VU in the second embodiment 

of a recording media management system of the present invention; 

Fig. 59 is an illustrative view showing a method of calculating the start address of a PRU in the second embodiment 
of a recording media management system of the present invention; 

Fig. 60 is an illustrative view showing the relationship between an arbitrary EU and PRUs in an EUS file, together 
10 with its Address LUT, in the second embodiment of a recording media management system of the present invention; 

Fig. 61 is an illustrative view showing relative address information in the Address LUT in the second embodiment 
of a recording media management system of the present invention; 

Fig. 62 is an illustrative view showing relative address information in the Address LUT in the second embodiment 
of a recording media management system of the present invention; 
15 Fig. 63 is an illustrative view showing Address Offset information in the second embodiment of a recording media 

management system of the present invention; and 

Fig. 64 is an illustrative view showing how MPEG data as a variable-length coding technique is recorded on a disk. 
Best Mode for Carrying Out the Invention 

20 

[0144] The embodiments of the present invention will be described hereinbelow with reference to the drawings. 
[The first embodiment] 

25 [0145] The first embodiment of a recording media management system of the present invention will be described in 
detail with reference to Figs.1 to 47. First, the MPEG stream composition to be handled in this embodiment will be 
described with reference to Figs.1 to 8. 

[0146] In the case when variable-length coded data such as MPEG data has been recorded on a recording medium 
such as a disk, memory device, or the like, in orderto realize random access such as starting playback from an arbitrary 
30 point or implementing special playback using only arbitrary selected frames, it is necessary to have management 
information for managing the positional information at which the wanted pieces of data are recorded on the disk. 
[0147] This is because the amount of data of each video frame of MPEG data recorded on the recording medium is 
variable, so that it is impossible to determine the recorded position of an arbitrary frame on the disk by calculation or 
other means. 

35 [0148] The description of the present embodiment will be described on the assumption that the MPEG technology 
is used as an example of variable-length coding with use of a disk as a recording medium. It should be understood 
that the present embodiment can be realized with use of semiconductor memory devices or others as the recording 
media, in a similar configuration to the case with use of a disk. 

[0149] To begin with, the structure of an MPEG stream to be handled in the embodiment will be described. It is 
40 assumed that video data is encoded at variable rates by the MPEG encoding and audio data, both the original and the 
post recording(audio dubbing) data, is encoded at a fixed rate. 

[0150] In the stream configuration shown in Fig. 1 , an editable unit sequence (to be abbreviated as 'EUS' hereinbelow) 
is composed of a multiple number of editable units (to be abbreviated as 'EUs' hereinbelow) and corresponds to the 
unit from start of recording (Rec Start) to the stop of recording (Rec Stop) or to a pause of recording (Rec Pause). The 
45 MPEG data managed by one EUS has to be added with time stamp which is the management information relating to 
sequential time. 

[0151] Here, EU is the minimum unit for destructive edit. Destructive edit means an act of editing accompanied by 
a move or deletion on the disk. The minimum unit of destructive edit means that move and deletion on the disk can be 
done only by EU by EU. 

50 [0152] If some EUs are deleted from the middle of one EUS by destructive edit, the time stamp of the MPEG stream 
presents discontinuity, so that the EUS needs to be divided. 

[0153] EU is composed of video units (to be abbreviated as 'VUs' hereinbelow) and a post recording unit (to be 
abbreviated as 'PRU' hereinbelow), and has to be recorded continuously on the disk. There may exist a stream con- 
figuration having no PRU. 

55 [0154] It is possible to add a constraint that the start position and end position of a PRU on the disk should be located 
at the boundary of error correction code block or ECC block. Since PRU is the area for post recording of data to be 
reproduced in synchronization with the video data within the EU, it should at least have an area size capable of recording 
the data equivalent to the presentation time of the video data in the EU. 
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[0155] As the EU structures, Fig. 1(a) shows the case where no EU header EU Header (to be abbreviated as 'EU 
Header' and to be described hereinbelow) is provided at the front of the EU and Fig. 1 (b) shows the case where an EU 
header is provided at the front of the EU. The EU Header is a packet added at the front of the EU for storing header 
information for managing the EU. When this EU Header is defined, the management information of the stream as to 

5 the EU can be recorded. 

[0156] VU is a unit comprised of a VU Header, one or greater number of GOPs of video data, and associated audio 
data. The presentation time of all the EUs and that of all the VUs in one EUS are set constant. The presentation time 
of VU corresponds to the playback time of video data managed by one VU. Similarly, the presentation time of EU 
indicates the playback time of video data managed by one EU. 

10 [0157] The EUS is divided into blocks having a fixed length of 2048 bytes. One block is stored into one logical block. 
Principally, one block is constructed of one packet. The packet used here conforms to PES Packet defined by ISO/I EC 
1381 8-1 , and packets of this type should be recorded onto the disk. 

[0158] Fig. 2 shows the relationship between the EUS and blocks. In this figure, a PRU is composed of a PRU header 
block PH BLK (to be abbreviated as 'PH BLK' hereinbelow), audio blocks A BLK (to be abbreviated as 'A BLKs') and 
15 padding blocks P BLK (to be abbreviated as 'P BLKs'). PH BLK stores a packet of the header information relating to 
the PRU. A BLK stores an audio packet defined by ISO/I EC 13818-3. P BLK stores a padding packet defined by ISO/ 
IEC 13818-1. 

[0159] A VU is composed of a VU header block VH BLK (to be abbreviated as 'VH BLK' hereinbelow), A BLKs (audio 
blocks) and video blocks V BLK (to be abbreviated as 'V BLKs'). VH BLK stores a packet of the header information 
20 relating to the VU. A BLK stores an audio packet defined by ISO/IEC 13818-3. V BLK stores a packet of video data 
defined by ISO/IEC 13818-2. 

[0160] For a stream where EU headers are defined, an EH header block EH BLK (to be abbreviated as 'EH BLK' 
hereinbelow) is stored at the front of each EU. 

[0161] The PRU area other than the header block PH BLK is padded with padding blocks (P BLKs) when no post 
25 recording data exists as in the initial state. When post recording is made, actual data such as of A BLKs or audio blocks 

is recorded. This audio data will be reproduced in synchronization with the video data within the corresponding VU. 

[0162] In a VU, the audio component is composed of a multiple number of A BLKs and the video data component 

is composed of a multiple number of V BLKs. This audio data will be reproduced in synchronization with the video data. 

[0163] When using a disk with an MPEG stream recorded thereon and playback from an arbitrary frame is started 
30 or a special playback such as reproducing arbitrarily selected frames is implemented, it is impossible, as stated above, 

to determine the recorded position of an arbitrary frame on the disk by calculation or the like because the amounts of 

data of individual frames of MPEG data recorded on the disk are different from one another. 

[0164] This is why management information for making an access to an arbitrary frame is needed. In this embodiment, 
this management information is called an address look up table (to be abbreviated as 'Address LUT' hereinbelow) and 

35 will be explained hereinbelow. The definitions of the terms used here will also be described. 

[0165] In this embodiment, post recording means audio dubbing that is the recording only sound afterwards overthe 
already recorded original data. A PRU is an area for recording post recording data when audio dubbing is implemented. 
[0166] Logical Block Number LBN (to be abbreviated as 'LBN' hereinbelow) is the address attached to each Logical 
Block as the minimum management unit on the disk offered by the logical filesystem. There exist areas, on the disk, 

40 which cannot be actually seen from the user side, such as areas to which data is written in, areas for recording error 
correction codes for written data, areas for substituting portions which are unable to be used in any way. 
[0167] To deal with this, the areas which can be actually used by the user can be assigned with addresses in as- 
cending order. This ascending order of addresses of user usable areas are called logical block numbers, and this 
management unit is called a logical block. A Relative Logical Block Number RLBN (to be abbreviated as 'RLBN' here- 

45 inbelow) indicates the relative representation of a logical block number. 

[0168] A Presentation Time Stamp PTS (to be abbreviated as 'PTS' hereinbelow) is a management format of the 
time stamp in the MPEG standard and is of 33 bits of data. This PTS is the information for mainly managing time at 
which MPEG data should be displayed, and the time information is represented by components of 90 KHz. 
[0169] Here, the most significant bit of the PTS component is removed so that it is handled as 32 bits of data. This 

50 is because it is unusual to handle data of 33 bits for microcomputer and the like and information of 32 bits is enough 
to provide sufficient management. This data which is converted to 32 bits is called PT (Presentation Time) Format 
(Figs. 5 and 7). 

[0170] RT (Real Time Stamp) Format (Figs. 5 and 6) is the format for management of the date at which the manage- 
ment information is created. ECC (Error Correction Code) is a code for correcting errors. This ECC is additionally 
55 recorded every determined unit when data is recorded on the disk. For example, one ECC is additionally recorded 
every 32 KB. 

[0171] In view of disk access, the unit of ECC is of a great significance because reading data from and writing data 
onto the disk is implemented in ECC block units. 
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[0172] When viewed from the user side, reading and writing can be implemented in logical block units. For example, 
if the size of one logical block is 2 KB, access can be implemented in 2 KB units. However, actual disk access for 
reading is implemented by reading out the ECC block including the data of 2 KB to be read and discarding unnecessary 
portion. 

5 [0173] For recording of 2 KB data, 30 KB of dummy data may be added, if some data has been written already, the 
written data should be once read out to replace the data to be modified and then the modified data is recorded onto 
the disk. In this way, it is necessary to be aware of ECC blocks to implement the high-speed disk access. 
[0174] Object ID (Figs. 5 to 7) is the ID for identifying individual management information. String (Figs. 5 and 6) is a 
format representing a character series. Unit N (Figs. 5 to 7) is a format for managing an integer of N bits with no sign. 

10 [0175] Address LUT is the management information for giving information as to the position on the disk to which an 
access should be made for an arbitrary frame in the MPEG data recorded on the disk. For this access, as the key 
information for designating an arbitrary frame the time information (time stamp) of the frame is used. 
[0176] Specifically, the Presentation Time PT (to be abbreviated as 'PT' hereinbelow) corresponding to an arbitrary 
frame is used to give the positions of the front ends (Fig. 3) of the VU and EU including the frame and the positions, 

15 on the disk, where data of the l-pictures and P-pictures within the VU has been recorded. When the stream has PRUs 
therein, the position on the disk where the PRU in the EU containing the VU starts is also determined by PT. 
[0177] It should be noted that the PT used here is information of 4 bytes of data, which has been attached to the 
MPEG stream or which is the corresponding PTS from which the most significant bit is removed. 
[0178] As shown in Fig. 3, in order to make an access to a target frame, the start address of the VU including that 

20 frame is given instead of locating the data of the frame on the disk. This is because in view of MPEG characteristics, 
the target frame, which is even in the VU, cannot be decoded if reference data such as l-pictures and P-pictures existing 
in that VU is not obtained. 

[0179] As an example, if an access needs to be made to the tenth frame of the video data recorded on the disk, the 
PTfor designating the tenth frame is given as 3003x10=30030. Here, 3003 is the PT-value, represented in decimal, 
25 corresponding to the presentation time of one frame, when NTSC video is encoded by the M PEG. That is, 30030 serves 
as the key information for locating the recorded position on the disk using Address LUT. 

[0180] As another example, when one VU has fifteen video frames, the total presentation time of one VU amounts 
to 1 5 x 3003 = 45045. If the frame wanted to be seen is the one-hundredth frame from the top frame, the VU number 
to which the frame belongs is (1 00x3030)/45045+1=7.67. From this calculation, the one-hundredth frame of video is 
30 known to be included in the seventh VU from the front. That is, it is understood that the management information of 
the seventh VU should be referred to. 

[0181] Next, description will be made of under what situation Address LUT may be used. A section of MPEG data 
recorded by the user from its recording start 'Rec Start 1 to recording stop 'Rec Stop 1 or to temporary stop 'Pause' is 
defined as one EUS. 

35 [0182] It is assumed that actual MPEG data is handled by EUS unit files, using a logical filesystem which manages 
the positional information of data on the disk by file names. This configuration is shown in Fig. 4. In this example, EUS0 
is managed as a file name of FDAV0000.EUS by the logical filesystem. 

[0183] Though this file name FDAV0000.EUS represents one EUS, on the actual disk, the data has been recorded 
in parts as file names EUS0-1 and EUSO-2, as shown in the figure. Similarly, EUS1 and EUS2 are managed as file 
40 names FDAV0001 .EUS and FDAV0002.EUS, respectively. 

[0184] To manage actual EUS data in EUS units, management information called 'EUS Information' is created. That 
is, if the user recorded multiple scenes, each corresponding to data from recording start 'Rec Start' to recording stop 
'Rec Stop', the same amount of management information 'EUS lnformation'(to be abbreviated as 'EUS Information' 
hereinbelow) is also created. 

45 [0185] One example of EUS Information is shown in Fig. 5. EUS Information is to manage an EUS recorded on the 
disk. As shown in the field name column in Fig. 5, this EUS Information has its ID for distinction, size, title information, 
creation date and updated date of the EUS, text information, thumbnail information for managing a representative 
thumbnail of the EUS, data ID for identifying the EUS file managed by the logical filesystem, data file size representing 
the data size of the EUS, property information such as EUS, video, audio, camera, post recording, source, copyright, 

50 still picture, etc. 

[0186] The EUS information also has reference information which reveals the programs which refer to the EUS 
managed thereby. Further, as the management information of importance, field names <Start PT>, <End PT>, <Post 
Recording Unit Size> and <Address LUT> can be mentioned. Hereinbelow, management information is represented 
by its field name enclosed by <>. 
55 [0187] Recorded into <Start PT> and <End PT> are PTS values, attached to the first and last display frames of the 
data stream of the EUS managed by this EUS Information, or the corresponding PTS value, converted in PT format. 
Since one EUS always manages video data having continuous time stamps, the total presentation time of the EUS 
can be calculated by subtracting <Start PT> from <End PT>, for example. 
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[0188] <Post Recording Unit Size> is the information as to the size of the PRU in each EU. It should be noted that 
the size of the PRU in each EU does not vary within the same EUS. <Address LUT> is the management information 
which provides where on the disk an access should be made to for an arbitrary frame in the MPEG data recorded on 
the disk. 

5 [0189] In the above way, based on the EUS Information, it is possibleto obtain the information as to an EUS recorded 
as a file on the disk. 

[0190] When the MPEG data recorded by the user is played back serially from the top in the recorded order, it is 
possible to perform playback without the aforementioned <Address LUT>. However, if, taking advantage of random 
accessibility of the disk, for example, the user tries to select an arbitrary number of arbitrary sections from EUSs which 
10 are the original data in its recorded state and reproduce in an arbitrary order, the management information of <Address 
LUT> will be needed. 

[0191] First, the management information for selecting an arbitrary number of arbitrary sections from one EUS as 
original data and reproducing the selected sections in an arbitrary order is assumed to be a program. This program 
manages the information for designating the EUS to be referenced to and start points and end points of arbitrary 
15 sections wanted to be selected from the data of that EUS. 

[0192] Fig. 6 shows one example of the management information of the program. As shown in Fig. 6, managed in a 
program is information including the ID for identifying the program, size, title, creation date, text information, represent- 
ative thumbnail of the program and the like. 

[0193] The information of importance related to the aforementioned <Address LUT> is the information of <Number 
20 of EUS Stream lnformation> and <EUS Stream Informations The information of <Number of EUS Stream lnformation> 
represents the number of scenes handled by this program. That is, an identical number of EUS Stream Information is 
recorded. 

[0194] As shown in Fig. 7, the management information <EUS Stream lnformation> manages <Referenced EUS ID> 
for managing the ID number of the management information <EUS lnformation> to which this scene refers, and <Start 
25 pt> and <End PT> indicating the selected EUS portion being referenced. The <Start PT> and <End PT> are recorded 
by values, attached to the referenced EUS or corresponding values, represented in an absolute PT system. Further, 
the EUS Stream Information can also manage the text information for this scene and a representative thumbnail of the 
scene. 

[0195] The program can be used to manage a plurality of sets of the information for designating EUSs and information 
30 as to start and end points thereof, whereby it becomes possible to select an arbitrary number of arbitrary sections and 
play them back in an arbitrary order. 

[0196] Fig. 8 shows the relationship between <EUS lnformation> and EUSs (actual data). As shown in Fig. 8, <Pro- 
gram #0> is a special program which corresponds to the entire video data on the disk and handled as the original 
program. In one word, this program permits the recorded entire video scenes to be viewed in the order recorded. 
35 [0197] The <Program #1> and downwards are freely editable programs which are created by the user and will be 
called user programs. <Program #1> in the example of the drawing manages three scenes. The first and second scenes 
are parts selected from <EUS#1> and the third scene is part selected from <EUS#2>. 

[0198] As above, in a user program, an arbitrary section from an arbitrary EUS can be selected as a scene. This is 
why the management information <Address LUT> becomes needed as stated above to reproduce the selected scenes. 
40 [0199] The way the user program is created by only management information without implementing duplication of 
actual data is called non-destructive edit. Since an arbitrary number of arbitrary sections are selected from the base 
material, i.e., original data, to perform playback in a desired order, this method does not need to use extra disk area, 
hence is markedly efficient. 

[0200] Next, referring to Figs. 9 through 18, the first example of the recording media management system of the 
45 present invention will be described taking a case of calculating the start addresses of the PRU and VU in the afore- 
mentioned MPEG stream and then determining the start address of the EU. 

[0201] To begin with, the layout of the PRU will be described. When the MPEG stream has PRUs therein, there is a 
possibility that the user may have implemented post recording. Therefore, when there exist PRUs, whether or not the 
PRUs have been used should be checked using aftermentioned <PRU Status> or <PR Existence> in <VU Status> 
50 (Figs. 11, 13 and 14). 

[0202] The information <PR Existence> in <PRU Status> of <PRU lnformation> is the management information 
showing whether post recording has been implemented in the associated EU. The information <PR Existence> in <VU 
Status> of <VU lnformation> is the management information showing whether there exists post recording data corre- 
sponding to the managed VU (Fig. 11). Depending on the aim it is possible to use either <PR Existence> of <PRU 
55 Status> or that of <VU Status> only. 

[0203] When a piece of post recording data exists and needs to be reproduced, it is necessary to read the post 
recording data beforehand prior to access to the target VU, then reproduce the read, post recording data in synchro- 
nization with the video when the video data is displayed. 
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[0204] In this way, use of the <PR Existence> information (Fig. 11) makes it possible to grasp beforehand whether 
or not post recording has been made, hence it is possible to eliminate unnecessary disk access because no access 
to PRU beforehand needs to be made when no post recording has been made. 

[0205] As shown in Figs. 9 and 10, there are two types of PRU layout on the disk, depending on the data geometry 
5 on the disk. This is attributed to the constraint that PRU should be aligned with an ECC boundary. That is, if the front 

of the EU happens to coincide with an ECC boundary, the PRU is disposed at the front of the EU, as shown in Fig. 9(b). 

[0206] On the other hand, when the front of the EU does not fall at an ECC boundary, the PRU is positioned to start 

from the ECC boundary that appears first from the front of the EU, as shown in Fig. 9(a). From the front end of the EU 

to the ECC boundary or the starting point of the PRU, part of the first VU in the EU is arranged. 
10 [0207] In the case where the EU has <EU Header> defined at the front thereof, if the end of <EU Header> happens 

to coincide with an ECC boundary, the PRU is disposed immediately after the <EU Header> as shown in Fig. 10(b), 

because of the constraint that PRU should be aligned with an ECC boundary. 

[0208] When the end of <EU Header> does not coincide with an ECC boundary, the PRU is positioned to start from 
the ECC boundary that appears first after the <EU Header>, as shown in Fig. 1 0(a). 
15 [0209] From the end of the <EU Header> to the starting point of the PRU, part of the first VU in the EU is arranged. 
The start address on the disk of the recorded PRU can be obtained from the information <RLBN of PRU> of <PRU 
Informations 

[021 0] Fig. 1 1 shows the content in <Address LUT> (Fig. 5). The definitions of the management information in Fig. 1 1 
will be described consecutively hereinbelow. Figs. 12 through 16 show the details of the management information in 
20 Fig. 11. 

[0211] In the figures, <Address Offset> stores an offset value for creating relative logical block numbers (RLBN) 
managed by the <address LUT>, in Unit 32 format. When an arbitrary number of EUs have been deleted from the front 
of the EUS, the number of the deleted logical blocks is set into this field. 

[0212] Accordingly, when referring to a relative logical block number (RLBN) used in <Address LUT>, it is necessary 
25 to subtract this <Address Offset> from that value, to refer to the number. The initial value of <Address Offset> has to 
be set at 0. 

[0213] <PB Time of EU> represents the set presentation time of each EU in the EUS managed by the <address 
LUT>. The set presentation time is the playback time of the video data in one EU and is constant in the same EUS, 
except the last EU in the EUS. 

30 [0214] <PB Time of EU> should be recorded in PT Format. Here, the information 'PB Time of EU' should be an 
integer multiple of the difference in PTS, represented in PT Format, between adjacent video frames in the MPEG 
stream, i.e., the PTS corresponding to the presentation time per frame. 

[0215] <PB Time of VU> represents the set presentation time of each VU in the EUS managed by the <address 
LUT>. The set presentation time is the playback time of the video data in one VU and is constant within the same EUS, 
35 except the last VU in the EUS. 

[0216] <PB Time of VU> should be recorded in PT Format. Here, the information 'PB Time of VU 1 should be an 
integer multiple of the difference in PTS, represented in PT Format, between adjacent video frames in the MPEG 
stream, i.e., the PTS corresponding to the presentation time per frame. 

[0217] <Number of PRU information> is the number of PRUs existing in the EUS managed by the <address LUT>, 
40 recorded in Unit 32 format. Since PRUs exist in one-to-one correspondence to EUs, the value of this field has the same 
value as the number of the EUs existing in the EUS. If there is no PRU existing in the stream configuration, this field 
should be always set at 0. 

[0218] <Number of VU lnformation> is the number of VUs existing in the EUS managed by the oddress LUT>, 
recorded in Unit 32 format. 

45 [0219] <PRU lnformation> manages the information as to each PRU in the EUS, in the manner as shown in Fig. 13. 
When there exists no PRU, the above <Number of PRU lnformation> is recorded with 0 and no record is written into 
<PRU Informations 

[0220] <RLBN of PRU> (Fig. 13) represents the start address on the disk of the PRU managed by this <PRU Infor- 
mations Here, the address is represented by the relative logical block number from the front of the EUS. <RLBN of 
50 PRU> should be recorded in Unit 24 format. <PRU Status> manages the state of the PRU managed by this <PRU 
Informations in the manner as shown in Fig. 14. 

[0221] <PR Existence> (BitO) (Fig. 14) is recorded with '1' when the PRU managed by this <PRU lnformation> (Fig. 
13) has post recording data and is recorded with '0' when no post recording data is present. When the presence of 
post recording data is managed in VU units, this field may not be used. 
55 [0222] <VU lnformation> (Fig. 12) manages the information as to each VU in the EUS, in the manner as shown in 
Fig. 1 5(a) or Fig. 1 5(b). It should be noted that in Fig. 1 5(a) the positional information of the video frames managed within 
the VU is given as either the start address or end address while in Fig. 15(b) the positional information is given as both 
the start address and the end address. 



18 



EP 1 206 135 A1 



[0223] <RLBN of VU> (Fig. 15) represents the start address on the disk of the VU managed by this <VU lnformation> 
(Fig. 12). This address is represented by the relative logical block number from the front of the EUS. <RLBN of VU> 
should be recorded in Unit 24 format. 

[0224] <VU Status> (Fig. 15) manages the state of the VU managed by this <VU lnformation> (Figs. 12 and 15), in 
the manner as shown in Fig. 16(a) or Fig. 16(b). Fig. 16(a) shows a case where <Non Contiguous Point> is defined and 
Fig. 1 6(b) shows a case where <Non Contiguous Point> is not defined. 

[0225] <PR Existence> (BitO) (Fig. 1 6) is recorded with 1 1 1 when post recording data corresponding to the VU managed 
by this <VU lnformation> (Figs. 12 and 15) is present and is recorded with '0' when no post recording data is present. 
If there exists no PRU in the EU, this field should be always recorded with '0'. When post recording (audio dubbing) is 
performed only in EU units, <PR Existence> in the aforementioned <PRU Status> can be used alone while this field 
may not be used. 

[0226] <Closed GOP> (Bit1) (Fig. 16) manages whether the first GOP in the VU is a closed GOP. If the GOP is a 
closed one, this field is recorded with '1'. Otherwise, it is recorded with '0'. When the GOP is not a closed one, there 
is a possibility that some of the first frames of video cannot be decoded without information of the previous GOP. 
[0227] <Non Contiguous Point> (Bit2) manages whether the EU to which the VU managed by this <VU lnformation> 
belongs is arranged on the disk logically and contiguously with the previous EU. When they are arranged contiguously, 
this field is recorded with '0'. When they are not arranged contiguously, the field is recorded with '1'. 
[0228] <Numberof IP Pictures> (Fig. 15) records the number of the positional information of l-pictures and P-pictures 
in the video data to be managed by this <VU lnformation> (Fig. 12), in Unit8 format. 

[0229] <End RLBN of IP Pictures> (Fig. 15(a)) manages the end addresses on the disk of the l-pictures and P-pictures 
in the VU managed by this <VU Informations The address herein is represented by the relative logical block number 
from the front of the VU. 

[0230] As the first entry the address information as to the first l-picture in the VU should be stored. As the second 
entry and downward, the address information as to l-pictures and/or P-pictures should be stored in Unit16 format. 
[0231] In connection with this, when a semiconductor memory having high-speed access performance is adopted 
as the recording medium or when a disk drive having markedly high-access performance is used, the start addresses 
should be also given as the positional information of the reference pictures, in addition to their end addresses. In this 
case, the field name of this item is renamed as <RLBN of IP Pictures> and both the start and end addresses should 
be recorded serially in Unit 16 format. 

[0232] It is also possible to putthe positional information of all the video frames under control, instead of the addresses 
of the reference pictures only. The positional information in this case should be represented by the record start position 
of each video frame on the disk. The amount of data of each frame and the end address can be calculated simply 
using the difference from the start address of the next frame. 

[0233] All the above is the management information of management information 'Address LUT'. 

[0234] Next, specific usage of these pieces of management information will be described with reference to Figs. 17 

and 18. 

[0235] Referring first to Figs. 17(a) and 17(b), description will be made of how to calculate the start address of the 
VU including a target frame. When start of playback is wanted from a frame corresponding to an arbitrary PT in an 
EUS, the starting position on the disk of the VU including that frame should be calculated based on <Address LUT>. 
[0236] The basic processing sequence for this will be as follows. Fig.1 7(a) shows a case without <EU Header> and 
Fig. 1 7(b) shows a case with <EU Header>. 

(1) Relative PT (Relative PTRPT) is calculated by the following equation, that is, by subtracting <Start PT> (Fig. 
5) corresponding to the first display frame in the EUS from the target PT (Fig. 17). <Start PT> is a PTS value, 
attached to the MPEG stream at the first display frame in the EUS, or the corresponding PTS value, converted in 
PT format. 

RPT = PT - Start PT 

As stated above, since the information as to the start point and end point, which is designated from each user 
program so as to select an arbitrary section, is represented by values, attached to the stream or corresponding 
values, represented in an absolute PT system, subtraction of <Start PT> from the values will provide relative time 
information from the front of the EUS. 

Here, the fact that absolute time information is used in user programs means that if, for example, some part 
in the front part of the EUS was deleted, there is no need to renew the start point and end point information of all 
the user programs which refer to this EUS as the reference information as long as the information <Start PT> in 
<EUS lnformation> (Fig. 5) is altered, thus making it possible to reduce the process load. 
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(2) <VU Information Number> (Fig. 11 ) of the VU including the frame from which the start of playback is wanted is 
obtained by dividing the relative PT (RPT) by the set presentation time (<PB Time of VU> (Figs. 1 2 and 1 7) of each 
VU in the EUS. In Fig. 17(a) this value is VU#7, and in Fig. 17(b) this value is VU#5. 

VU Info Num = ip(RPT/PB Time of VU), 
where ip(n) is a function that produces the maximum integer not greater than n. 

(3) From the obtained <VU Information Number> (Fig. 1 1 ) , the start address of the VU including the target frame 
10 is obtained as the relative logical block number 'RLBN of VU" (Fig. 11) from the front of EUS (Fig. 17). 

RLBN of VU 1 = RLBN of VU(VU Info Num), 

15 where expression RLBN of VU(n) represents the value of <RLBN of VU> (Fig. 11 ) of the nth <VU Informations 

[0237] In the above way, the start address of the VU including a target frame can be determined by simple calculation 
using <Address LUT>, instead of searching or other operations. 

[0238] Next, referring to Fig. 1 8, description will be made of how to calculate the start address of the PRU in the EU 
20 including a target frame. The basic sequence of calculating the start address of the PRU in the EU including the target 
frame will be as follows. Fig. 1 8(a) shows a case with no <EU Header> and Fig. 1 8(b) shows a case with <EU Header>. 
[0239] The frontmost end of the PRU is a point which needs to be accessed when post recording data corresponding 
to the target frame is present. 

25 (1) Relative PT (Relative PT: RPT) is calculated by subtracting <Start PT> (Figs.5 and 18) corresponding to the 

first display frame in the EUS from the target PT. 

RPT = PT - Start PT 

30 

(2) The number of the EU including the frame from which the start of playback is wanted is obtained by dividing 
the relative PT (RPT) by the set presentation time (<PB Time of EU> in Figs. 12 and 18) of each EU in the EUS. 
In Fig.1 8 this value is EU#1 . Since each EU corresponds to one PRU, this EU number #1 directly represents <PRU 
Information Number> (Fig. 11). 

35 

PRU Info Num = ip(RPT/PB Time of EU), 

where ip(n) is a function that produces the maximum integer not greater than n. 
40 (3) From the obtained <PRU Information Number> (Fig .11), the start address of the PRU in the EU including the 

target frame is obtained as the relative logical block number'RLBN of PRU' 1 (Figs. 11 and 18) from the front of EUS. 

RLBN of PRU' = RLBN of PRU(PRU Info Num). 

45 

[0240] In the above way, similarly to the way of determining the VU start address, the start address of the PRU to 
be reproduced in synchronization with the VU including a target frame can be determined by simple calculation using 
<Address LUT>, instead of searching or other operations. 

[0241] Next, description will be made of how to calculate the start of the EU including a target frame. The frontmost 
50 end of the EU including the target frame is equivalent to the frontmost end of the first VU in the EU when the stream 
has no PRU therein. When PRUs are present in the stream, there are two cases as stated already, depending on the 
PRU layout (Fig. 9). 

(1 ) When the front of the EU starts from an ECC boundary (Fig. 9(b)), the frontmost end of EU is equivalent to the 
55 frontmost end of the PRU. 

(2) When the front of the EU does not start from an ECC boundary (Fig. 9(a)), the frontmost end of EU is equivalent 
to the frontmost end of the first VU included in the EU. 
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[0242] Accordingly, when frontmost end of the EU needs to be determined, by comparing the start address of the 
PRU in the observed EU with the start address of the first VU included in the EU, the one recorded earlier can be 
interpreted as the frontmost end of the EU. 

[0243] Here, <VU Information Number> (Fig. 11) representing the first VU included in the EU is determined by the 
5 following equation: 

VU Info Num = ip(RPT/PB Time of EU)*(PB Time of EU/PB Time of VU), 

10 where ip(n) is a function that produces the maximum integer not greater than n. 

[0244] When the EU has a header defined at its front for managing the EU (Fig. 10), it is possible to determine the 
frontmost end of the EU by comparing the start address of the PRU in the observed EU with the start address of the 
first VU included in the EU and subtracting the size of the header from the address of that recorded earlier. 
[0245] Next, referring to Figs. 1 9 through 29, the second example of the recording media management system of the 

15 present invention will be described taking a case where the start addresses of the EU and VU in the aforementioned 
MPEG stream are calculated and then the start address of the PRU is determined. 

[0246] To begin with, the layout of the PRU will be described. When the MPEG stream has PRUs therein, there is a 
possibility that the user may have implemented post recording. Therefore, when there exist PRUs, whether or not the 
PRUs have been used should be checked using aftermentioned <EU Status> or <PR Existence> in <VU Status>. 

20 [0247] <PR Existence> in <EU Status> of <EU lnformation> is the management information showing whether post 
recording has been implemented in the associated EU. <PR Existence> in <VU Status> of <VU lnformation> is the 
management information showing whether there exists post recording data corresponding to the managed VU. De- 
pending on the aim it is possible to use either <PR Existence> of <EU Status> or that of <VU Status> only. 
[0248] When a piece of post recording data exists and needs to be played back, it is necessary to read the post 

25 recording data beforehand prior to access to the target VU. 

[0249] In this way, use of the <PR Existence> information makes it possible to grasp beforehand whether or not post 
recording has been made, it is possible to eliminate unnecessary disk access because no access to PRU beforehand 
needs to be made when no post recording has been made. 

[0250] As shown in Figs. 19 and 20, there are two types of PRU layout on the disk, depending on the data geometry 
30 on the disk. This is attributed to the constraint that PRU should be aligned with an ECC boundary. That is, if the front 

of the EU happens to coincide with an ECC boundary, the PRU is disposed at the front of the EU , as shown in Fig. 1 9(b). 

[0251] On the other hand, when the front of the EU does not fall at an ECC boundary, the PRU is positioned to start 

from the ECC boundary that appears first from the front of the EU, in the manner as shown in Fig.1 9(a). From the front 

of the EU to the ECC boundary or the starting point of the PRU, part of the first VU in the EU is arranged. 
35 [0252] In the case where the EU has <EU Header> defined in the front thereof, if the end of <EU Header> happens 

to coincide with an ECC boundary, the PRU is disposed immediately after the <EU Header> as shown in Fig. 20(b), 

because of the constraint that PRU should be aligned with an ECC boundary. 

[0253] When the end of <EU Header> does not coincide with an ECC boundary, the PRU is positioned to start from 
the ECC boundary that appears first after the <EU Header>, as shown in Fig. 20(a). From the end of the <EU Header> 
40 to the starting point of the PRU, part of the first VU in the EU is arranged. 

[0254] Recorded in <PRU Position> in the <EU Status> shown in Fig. 21 is the distance from the front of the EU to 
the starting point of the PRU. This distance is represented by the number of logical blocks and is 15 logical blocks at 
maximum. 

[0255] Fig. 21 shows the content in <Address LUT> (Fig. 5). The definitions of the management information in Fig. 21 
45 will be described serially hereinbelow. Figs. 22 through 26 show the details of the management information in Fig. 21 . 
[0256] In the figures, <Address Offset> stores an offset value for creating relative logical block numbers (RLBN) 
managed by the <address LUT>, in Unit 32 format. When an arbitrary number of EUs have been deleted from the front 
part of the EUS, the number of the deleted logical blocks is set into this field. 

[0257] Accordingly, when referring to a relative logical block number (RLBN) used in <Address LUT>, it is necessary 
50 to subtract this <Address Offset> from that value, to refer to the number. The initial value of <Address Offset> has to 
be set at 0. 

[0258] <PB Time of EU> represents the set presentation time of each EU in the EUS managed by the <address 
LUT>. The set presentation time is the playback time of video data in one EU and is constant within the same EUS, 
except the last EU in the EUS. 

55 [0259] Further, <PB Time of EU> should be recorded in PT Format. Here, the information 'PB Time of EU' should 
be an integer multiple of the difference in PTS, represented in PT Format, between adjacent video frames in the MPEG 
stream, i.e., the PTS corresponding to the presentation time per frame. 

[0260] <PB Time of VU> represents the set presentation time of each VU in the EUS managed by the <address 
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LUT>. The set presentation time is the playback time of video data in one VU and is constant within the same EUS, 
except the last VU in the EUS. 

[0261] <PB Time of VU> should be recorded in PT Format. Here, the information <PB Time of VU> should be an 
integer multiple of the difference in PTS, represented in PT Format, between adjacent video frames in the MPEG 
5 stream, i.e., the PTS corresponding to the presentation time per frame. 

[0262] <Number of EU lnformation> is the number of EUs existing in the EUS managed by the oddress LUT>, 
recorded in Unit 32 format. <Number of VU lnformation> is the number of VUs existing in the EUS managed by the 
oddress LUT>, and recorded in Unit 32 format. 

[0263] <EU lnformation> (Fig. 12) manages the information as to each EU in the EUS, in a manner as shown in Fig.23. 
10 [0264] <RLBN of EU> represents the start address on the disk of the EU managed by this <EU Informations This 
address is represented by the relative logical block numberfrom the front of the EUS. <RLBN of EU> should be recorded 
in Unit 24 format. 

[0265] <EU Status> manages the status of the EU managed by this <EU Informations in the manner as shown in 
Fig. 24(a) or Fig.24(b). 

15 [0266] <PRU Position> (BitO-4) (Fig.24) records the information as to the position of the PRU in this EU. <PRU 
Position> represents the starting position of the PRU in the EU by the distance (LBN number) from the front of the EU. 
[0267] If the PRU is located at the front of the EU, this field is recorded with 0, if not, the distance from the front of 
EU is recorded by a value ranging from 1 to 1 6 logical blocks. When no PRU exists within the EU, this field is constantly 
set at 0. 

20 [0268] <PR Existence> (Bit5) (Fig.24) is recorded with '1' when post recording data corresponding to the EU managed 
by this <EU lnformation> is present, and this field is recorded with '0' when no post recording data is present. When 
no PRU is present in the EU, this field should be always recorded with '0'. When the presence of post recording data 
is managed for each VU, the above field may not be used. 

[0269] <Non Contiguous Point> (Bit6) (Fig. 24(b)) manages whether the EU managed by this <EU lnformation> is 
25 arranged on the disk logically and contiguously with the previous EU. When they are arranged contiguously, this field 
is recorded with '0'. When they are not arranged contiguously, the field is recorded with '1'. This information can be 
optionally introduced. 

[0270] <VU lnformation> (Fig. 22, 22) manages the information as to each VU in the EUS, in the manner as shown 
in Fig. 25(a) or Fig. 25(b). It should be noted that in Fig. 25(a) the positional information of the video frames managed 
30 within this VU is given as either the start address or end address while in Fig. 25(b) the positional information is given 
as both the start address and the end address. 

[0271] <RLBN of VU> represents the start address on the disk of the VU managed by this <VU Informations This 
address is represented by the relative logical block numberfrom the front of the EUS. <RLBN of VU> should be recorded 
in Unit 24 format. 

35 [0272] <VU Status> manages the state of the VU managed by this <VU lnformation> in the manner as shown in Fig. 
26. 

[0273] <PR Existence> (BitO) (Fig. 26) is recorded with '1' when post recording data corresponding to the VU managed 
by this <VU lnformation> is present. This field is recorded with '0' when no post recording data is present. If there exists 
no PRU in the EU, this field should be always recorded with '0'. When post recording is performed only in EU units, 

40 <pr Existence> in the aforementioned <PRU Status> (Fig.24) can be used alone while this field may not be used. 
[0274] <Closed GOP> (Bit1) (Fig. 26) manages whether the first GOP in the VU is a closed GOP. If the GOP is a 
closed one, this field is recorded with '1'. Otherwise, it is recorded with '0'. When the GOP is not a closed one, there 
is a possibility that some of the first frames of video cannot be decoded without information of the previous GOP. 
[0275] <Number of IP Pictures> (Fig. 25) records the number of the positional information of l-pictures and P-pictures 

45 in the video data to be managed by this <VU Information^ in Unit 8 format. 

[0276] <End RLBN of I P Pictures> (Fig.25(a)) manages the end addresses on the disk of the l-pictures and P-pictures 
in the VU managed by this <VU Informations The address herein is represented by the relative logical block number 
from the front of the VU. 

[0277] As the first entry the address information as to the first l-picture in the VU should be stored. As the second 
50 entry and downward, the address information as to l-pictures or P-pictures should be stored in Unit 1 6 format. 

[0278] In connection with this, when a semiconductor memory having high-speed access performance is adopted 
as the recording medium or when a disk drive having markedly high-access performance is used, the start addresses 
should be also given as the positional information of the reference pictures, in addition to their end addresses. In this 
case, the field name of this item is renamed as <RLBN of IP Pictures> and both the start address and end address 
55 should be recorded serially in Unit 1 6 format. 

[0279] It is also possible to manage the positional information of all the video frames, instead of the addresses of 
the reference pictures only. The positional information in this case should be represented by the record start position 
of each video frame on the disk. The amount of data of each frame and the end address can be calculated simply 
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using the difference from the start address of the next frame. 

[0280] All the above is the management information in <Address LUT> (Figs. 5 and 21). Next, specific usage of these 
pieces of management information will be described with reference to Figs. 27 to 29. 

[0281] First, description will be made of how to calculate the start address of the VU including a target frame. 
5 [0282] When playback is desired to be started from a frame corresponding to an arbitrary PT in an EUS, the starting 
position on the disk of the VU including this frame should be determined based on <Address LUT>. 
[0283] The basic processing sequence for this will be as follows. Fig. 27(a) shows a case with no <EU Header> and 
Fig. 27(b) shows a case with <EU Header>. 

10 (1) Relative PT (FtPT) is calculated by the following equation, that is, by subtracting <Start PT> (Figs. 5 and 27) 

corresponding to the first display frame in the EUS from the target PT 

RPT = PT - Start PT 

15 

As stated above, since the information as to the start point and end point, which is designated from each user 
program so as to select an arbitrary section, is represented by values, attached to the stream or corresponding 
values, represented in an absolute PT system, subtraction of <Start PT> from that values will provide relative time 
information from the front of the EUS. 
20 Here, the fact that absolute time information is used in user programs means that if, for example, some part 

in the front part of the EUS was deleted, there is no need to renew the start point and end point information of all 
the user programs which refer to this EUS as the reference information as long as the information <Start PT> in 
<EUS lnformation> (Fig. 5) is modified, thus making it possible to reduce the process load. 

(2) Next, <VU Information Number> (Fig. 21) of the VU including the frame from which the start of playback is 
25 desired is obtained by dividing the relative PT (RPT) determined by the following equation by the set presentation 

time (<PB Time of VU> (Figs.20 and 27)) of each VU in the EUS. In Fig.27(a) this value is 'VU info #5'. 

VU Info Num = ip(RPT/PB Time of VU), 

30 

where ip(n) is a function that produces the maximum integer not greater than n. 

(3) From the obtained <VU Information Number>, i.e., the fifth VU in Fig. 27, the start address of the VU including 
the target frame is obtained as the relative logical block number 'RLBN of VU' 1 (Figs. 21 , 25 and 27) from the front 
of EUS. 

35 

RLBN of VU 1 = RLBN of VU(VU Info Num), 
where RLBN of VU(n) represents the value of 'RLBN of VU' of the nth 'VU Information'. 

40 

[0284] In the above way, the start address of the VU including a target frame can be determined by simple calculation 
using <Address LUT>, instead of searching or other operations. 

[0285] Next, referring to Fig. 28, description will be made of how to calculate the start address of the EU including a 
target frame. The basic sequence of calculating the start address of the EU including the target frame will be as follows. 
45 [0286] When header information for managing the EU is defined at the front of the EU, the frontmost end of the EU 
means the starting position of <EU Header> on the disk. Fig. 28(a) shows a case with no <EU Header> and Fig.28(b) 
shows a case having <EU Header>. 

(1) Relative PT (RPT) is calculated by subtracting <Start PT> (Fig. 5) corresponding to the first display frame in 
50 the EUS from the target PT. 

RPT = PT - Start PT 

55 (2) <EU Information Number> of the EU including the frame from which the start of playback is desired is obtained 

by dividing the relative PT (RPT) obtained in (1 ) by the set presentation time (<PB Time of EU> (Figs. 22 and 28) 
of each EU in the EUS. In Fig.28 this value is EU#1 . 
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EU Info Num = ip(RPT/PB Time of EU), 

where ip(n) is a function that produces the maximum integer not greater than n. 
5 (3) From the <EU Information Number> obtained in (2), the start address of the EU including the target frame is 

obtained as the relative logical block number 'RLBN of EU" from the front of EUS (Fig. 21). 

RLBN of EU' = RLBN of EU(EU Info Num) 

10 

[0287] Similarly to the way of determining the start address of VU, the start address of the EU including a target 
frame can be determined by simple calculation using <Address LUT>, instead of searching or other operations. 
[0288] Next, description will be made of how to calculate the start address of the PRU in the EU including a target 
frame. The basic sequence of calculating the start address of the PRU in the EU including the target frame will be as 
15 follows. Fig. 29(a) shows a case with no <EU Header> and Fig. 29(b) shows a case with <EU Header>. 

[0289] The frontmost end of the PRU is a point which needs to be accessed to when post recording data correspond- 
ing to the target frame is present. 

(1) Relative PT (RPT) is calculated by subtracting <Start PT> (Figs. 5 and 29) corresponding to the first display 
20 frame in the EUS from the target PT. 

RPT = PT - Start PT 

25 (2) <EU Information Number> of the EU including the frame from which the start of playback is desired is obtained 

by dividing the relative PT (RPT) by the set presentation time (<PB Time of EU> (Figs. 21 and 29) of each EU in 
the EUS. In Fig.29 this value is EU#1 . 

30 EU Info Num = ip(RPT/PB Time of EU), 

where ip(n) is a function that produces the maximum integer not greater than n. 

(3) From the obtained <EU Information Number>, the start address of the EU including the target frame is obtained 
as the relative logical block number 'RLBN of EU' 1 (Fig. 21) from the front of EUS. 

35 

RLBN of EU' = RLBN of EU(EU Info Num). 

(4) The relative logical block number 'RLBN of PRU' from the front of the EUS including the target PRU is obtained 
40 by adding the value of <PRU Position> in <EU Status> (Fig.24) to the start address 'RLBN of EU" of the target EU : 

RLBN of PRU - RLBN of EU' + PRU Position. 

45 [0290] Thus, similarly to the way of determining the start address of VU, the start address of the PRU to be reproduced 
in synchronization with the VU including a target frame can be determined by simple calculation using <Address LUT>, 
instead of searching or other operations. 

[0291] Next, referring to Figs. 30 through 39, the third example of the recording media management system of the 
present invention will be described by taking a case where the start address of the VU in the aforementioned MPEG 
so stream is calculated and then the start addresses of the EU and PRU are determined. 

[0292] To begin with, the layout of PRU will be described. When the MPEG stream has PRUs therein, there is a 
possibility that the user may have implemented post recording. If there exist PRUs, whether or not the PRUs have 
been used should be checked using <PR Existence> in <VU Status> (Fig. 32). 

[0293] When a piece of post recording data exists and needs to be played back, it is necessary to read the post 
55 recording data beforehand prior to the access to the target VU. 

[0294] In this way, use of the <PR Existence> information makes it possible to grasp beforehand whether or not post 
recording has been made and it is possible to eliminate unnecessary disk access because no access to PRU data 
needs to be made beforehand when no post recording has been made. 
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[0295] As shown in Figs. 30 and 31 , there are two types of PRU layout on the disk, depending on the data geometry 

on the disk. This is attributed to the constraint that PRU should be aligned with an ECC boundary. That is, if the front 

of the EU happens to coincide with an ECC boundary, the PRU is disposed at the front of the EU , as shown in Fig. 30(b). 

[0296] On the other hand, when the front of the EU does not fall at an ECC boundary, the PRU is positioned to start 
5 from the ECC boundary that appears first from the top of the EU, in the manner as shown in Fig. 30(a). From the front 

end of the EU to the ECC boundary or the starting point of the PRU, part of the first VU in the EU is arranged. 

[0297] In the case where the EU has <EU Header> defined in the front thereof, if the end of <EU Header> happens 

to coincide with an ECC boundary, the PRU is disposed immediately after the <EU Header> as shown in Fig. 31(b), 

because of the constraint that PRU should be aligned with an ECC boundary. 
10 [0298] When the end of <EU Header> does not coincide with an ECC boundary, the PRU is positioned to start from 

the ECC boundary that appears first after the <EU Header>, as shown in Fig. 31 (a). From the end of the <EU Header> 

to the starting point of the PRU, part of the first VU in the EU is arranged. 

[0299] Recorded in <PRU Position> in the <VU Status> shown in Fig. 32 is the distance from the front of the EU to 
the starting point of the PRU. This distance is represented by the number of logical blocks and is 1 6 logical blocks at 
15 maximum. 

[0300] Fig. 32 shows the content in <Address LUT> (Fig. 5). The definitions of the management information in Fig. 32 
will be described serially hereinbelow. Figs. 33 through 37 show the details in Fig. 32. 

[0301] In the figures, <Address Offset> stores an offset value for creating relative logical block numbers (RLBN) 
managed by the <address LUT>, in Unit 32 format. When an arbitrary number of EUs have been deleted from the front 
20 part of the EUS, the number of the deleted logical blocks is set into this field. 

[0302] Accordingly, when referring to a relative logical block number (RLBN) used in <Address LUT>, it is necessary 
to subtract this <Address Offset> from that value, to refer to the number. The initial value of <Address Offset> has to 
be set at 0. 

[0303] <PB Time of EU> represents the set presentation time of each EU in the EUS managed by the oddress 
25 LUT>. The set presentation time is the playback time of video data in one EU and is constant within the same EUS, 
except the last EU in the EUS. 

[0304] <PB Time of EU> should be recorded in PT Format. Here, the information <PB Time of EU> should be an 
integer multiple of the difference in PTS, represented in PT Format, between adjacent video frames in the MPEG 
stream, i.e., the PTS corresponding to the presentation time per frame. 
30 [0305] <PB Time of VU> represents the set presentation time of each VU in the EUS managed by the oddress 
LUT>. The set presentation time is the playback time of video data in one VU and is constant within the same EUS, 
except the last VU in the EUS. 

[0306] <PB Time of VU> should be recorded in PT Format. Here, the information <PB Time of VU> should be an 
integer multiple of the difference in PTS, represented in PT Format, between adjacent video frames in the MPEG 
35 stream, i.e., the PTS corresponding to the presentation time per frame. 

[0307] <Number of VU lnformation> is the number of VUs existing in the EUS managed by the oddress LUT>, 
recorded in Unit 32 format. 

[0308] <VU lnformation> manages the information as to each VU in the EUS, in the manner as shown in Fig.34(a) 
or Fig. 34(b). It should be noted that in Fig. 34(a) the positional information of the video frames managed within the VU 
40 is given as either the start address or end address while in Fig. 34(b) the positional information is given as both the 
start address and the end address. 

[0309] <RLBN of VU> (Fig. 34) represents the start address on the disk of the VU managed by this <VU Informations 
This address is represented by the relative logical block number from the front of the EUS. 'RLBN of VU' should be 
recorded in Unit 24 format. 

45 [0310] <VU Status> in Fig. 34 manages the state of the VU managed by this <VU Informations in the manner as 
shown in Fig. 35(a) or Fig. 35(b). Fig. 35(a) shows a case where <Non Contiguous Point> information is defined and 
Fig. 35(b) shows a case where <Non Contiguous Point> information is not defined. 

[0311] <PRU Position> (BitO-4) (Fig. 35) records the information as to the position of the PRU in the EU including 
this VU. <PRU Position> represents the starting position of the PRU in the EU by the distance (LBN number) from the 
50 front of the EU. 

[0312] If the PRU is located from the front of the EU, this field is recorded with 0, if not, the distance from the front 
of EU is recorded by a value ranging from 1 to 15 of logical blocks. When no PRU exists within the EU, this field should 
be constantly set at 0. 

[0313] <PR Existence> (Bit5) (Fig. 35) is recorded with '1' when post recording data corresponding to the VU managed 
55 by this <VU lnformation> is present, and this field is recorded with '0' when no post recording data is present. When 
no PRU is present in the EU, this field should be always recorded with '0'. 

[0314] <Closed GOP> (Bit6) (Fig. 35) manages whether the first GOP in the VU is a closed GOP. If the GOP is a 
closed one, this field is recorded with '1'. Otherwise, it is recorded with '0'. When the GOP is not a closed one, there 
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is a possibility that some of the first frames of video in GOP cannot be decoded without information of the previous GOP. 
[0315] <Non Contiguous Point> (Bit7) (Fig. 35(b)) manages whether the EU including the VU managed by this <VU 
lnformation> (Figs. 32 to 34) is arranged on the disk logically and contiguously with the previous EU. When they are 
arranged contiguously, this field is recorded with '0'. When they are not arranged contiguously, the field is recorded 
5 withT. 

[0316] <Numberof IP Pictures> in Figs. 32 and 34 records the number of the positional information of l-pictures and 
P-pictures in the video data to be managed by this <VU Informations in Unit8 format. 

[0317] <End RLBN of IP Pictures> (Fig. 34(a)) manages the end addresses on the disk of the l-pictures and P-pictures 
in the VU managed by this <VU Informations The address herein is represented by the relative logical block number 

10 from the front of the VU. 

[0318] As the first entry the address information as to the first l-picture in the VU should be stored. As the second 
entry and downward, the address information as to l-picture or P-picture should be stored in Unit 16 format. 
[0319] In connection with this, when a semiconductor memory having high-speed access performance is adopted 
as the recording medium or when a disk drive having markedly high-access performance is used, the start addresses 

15 also should be given as the positional information of the reference pictures, in addition to their end addresses. In this 
case, the field name of this item is renamed as <RLBN of IP Pictures> and both the start address and end address 
should be recorded serially in Unit 16 format. 

[0320] It is also possible to manage the positional information of all the video frames, instead of the addresses of 
the reference pictures only. The positional information in this case should be represented by the record start position 
20 of each video frame on the disk. The amount of data of each frame or the end address can be calculated simply using 
the difference from the start address of the next frame. 
[0321] All the above is the management information in <Address LUT>. 

[0322] Next, specific usage of these pieces of management information will be described with reference to Figs. 36 
to 39. 

25 [0323] Referring to first to Fig. 36, description will be made of how to calculate the start address of the VU including 
a target frame. When playback is desired to be started from a frame corresponding to an arbitrary PT in an EUS, the 
starting position on the disk of the VU including this frame should be determined based on <Address LUT>. 
[0324] The basic processing sequence for this will be as follows. Fig. 36(a) shows a case with no <EU Header> and 
Fig. 36(b) shows a case with <EU Header>. 

30 

(1) Relative PT (PRT) is calculated by subtracting <Start PT> (Figs. 5 and 36) corresponding to the first display 
frame in the EUS from the target PT. 

35 RPT = PT - Start PT 

As stated above, since the information as to the start point and end point, which is designated from each user 
program so as to select an arbitrary section, is represented by values, attached to the stream or corresponding 
values, represented in the absolute PT system, subtraction of <Start PT> from that values will provide relative time 

40 information from the front of the EUS. 

Here, the fact that absolute time information is used in user programs means that if, for example, some part 
in the front part of the EUS was deleted, there is no need to renew the start point and end point information of all 
the user programs which refer to this EUS as the reference information as long as the information <Start PT> in 
<EUS lnformation> (Fig. 5) is modified, thus making it possible to reduce the process load. 

45 (2) The <VU lnformation> number (Fig. 32) of the VU including the frame from which the start of playback is desired 

is obtained by dividing the relative PT (RPT) by the set presentation time (<PB Time of VU> (Figs.32 and 33) of 
each VU in the EUS. In Fig.36 this value is VU#5. 

50 VU Info Num = ip(RPT/PB Time of VU), 

where ip(n) is a function that produces the maximum integer not greater than n. 

(3) From the obtained <VU Information Number>, the start address of the VU including the target frame is obtained 
as the relative logical block number 'RLBN of VU" (Figs.32 and 36) from the front of EUS. 

55 

RLBN of VU' = RLBN of VU(VU Info Num), 
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where expression 'RLBN of VU(n)' represents the value of <RLBN of VU> of the nth <VU Informations 

[0325] In the above way, the start address of the VU including a target frame can be determined by simple calculation 
using <Address LUT>, instead of searching or other operations. 
5 [0326] Next, description will be made of how to calculate the start address of the EU including a target frame. The 
basic sequence of calculating the start address of the EU including the target frame will be as follows. When <EU 
Header> is defined at the front of the EU, the front of the EU means the starting position of <EU Header> on the disk. 

(1) Relative PT (RPT) is calculated by subtracting <Start PT> corresponding to the first display frame in the EUS 
10 from the target PT. 

RPT = PT - Start PT 

15 (2) The EU Number of the EU including the frame from which the start of playback is desired is obtained by dividing 

the relative PT (RPT) by the set presentation time (<PB Time of EU>) of each EU in the EUS. 

EU Number = ip(RPT/PB Time of EU), 

20 

where ip(n) is a function that produces the maximum integer not greater than n. 

(3) The number of VUs included in one EU is determined by dividing the set presentation time of each EU (<PB 
Time of EU>) by the set presentation time of each VU (<PB Time of VU>) 

VU per EU = PB Time of EU/PB Time of VU 

(4) <VU Information Number> of the VU at the front in the EU is obtained by multiplying the EU number of the EU 
including the frame from which the start of playback is desired, by the number of VUs included in one EU. 

30 

VU Info Num = EU Number * VU per EU 

(5a) When <PRU Position> (Fig. 35) in <VU Status> managed by the <VU lnformation> (Figs. 32 and 34) at the 
35 front of the target EU is other than '0', the start address of the VU in the <VU lnformation> represents the relative 

logical block number 'RLBN of EU' from the front of the EUS to which the target EU belongs, as shown in Fig. 37(a). 

RLBN of EU = RLBN of VU(VU Info Num) 

40 

(5b) When <EU Header> is defined at the front of the EU and when <PRU Position> (Fig. 35) in <VU Status> 
managed by the <VU lnformation>(Figs.32 and 34) at the front of the target EU is other than '0', the relative logical 
block number 'RLBN of EU' from the front of the EUS to which the target EU belongs can be obtained by subtracting 
the size of <EU Header> (2KB) from the start address of the VU (RLBN of VU) in the <VU Information;^ as shown 
45 in Fig.37(b). 

RLBN of EU = RLBN of VU(VU Info Num) - EU Header Size. 

so (5c) When <PRU Position> in <VU Status> managed by the <VU lnformation> at the front of the target EU is '0', 

the relative logical block number 'RLBN of EU' from the front of the EUS to which the target EU belongs can be 
obtained by subtracting the size of PRU from the start address of the VU (RLBN of VU) in the <VU Informations 
as shown in Fig. 38(a). 

RLBN of EU = RLBN of VU(VU Info Num) - PRU Size. 
(5d) When <PRU Position> in <VU Status> managed by the <VU lnformation> at the front of the target EU is '0', 
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the relative logical block number 'RLBN of ELT from the front of the EUS to which the target EU belongs can be 
obtained by subtracting the size of PRU and the size of <EU Header> (2 KB) from the start address of the VU 
(RLBN of VU) in the <VU Information^ as shown in Fig. 38(b). 

RLBN of EU = RLBN of VU(VU Info Num) - PRU Size - EU Header Size. 

[0327] In the above way, the start address of the EU including a target frame can be determined, in a similar manner 
to the way the start address of the VU is determined, by simple calculation using <Address LUT>, instead of searching 
10 or other operations. 

[0328] Next, description will be made of how to calculate the start address of the PRU in the EU including a target 
frame. The basic sequence of calculating the start address of the PRU in the EU including the target frame will be as 
follows. Fig. 39(a) shows a case with no <EU Header> and Fig. 39(b) shows a case with <EU Header>. 
[0329] The frontmost end of the PRU is a point which needs to be accessed to when post recording data correspond- 
15 jng to the target frame is present. 

(1 ) Similar to the above-described case where the start address of the EU including a target frame is calculated, 
the start address 'RLBN of EU of the target EU is determined. 

(2) The relative logical block number 'RLBN of PRU' from the front of the EUS to which the target PRU belongs 
20 can be obtained by adding the value of the <PRU Position> managed by the first <VU lnformation> in the EU and 

the size of <EU Header> (2KB) to the start address 'RLBN of EU' of the target EU. 

RLBN of PRU = RLBN of EU + EU Header Size + PRU Position. 

25 

[0330] In the above way, the start address of the PRU to be reproduced in synchronization with the VU including a 
target frame can be determined, in a similar manner to the way the start address of the VU is determined, by simple 
calculation using <Address LUT>, instead of searching or other operations. 

[0331] In the above first to third examples of the present invention, the address information obtained from <Address 
30 LUT> is represented in a relative address system, so that for disk access it is necessary to convert the information into 
the logical address system of the disk. Next, description will made of how to calculate a logical address on the disk 
from a relative address. 

[0332] As already described, an EUS is managed as a file using the logical filesystem. Even when a certain EUS is 
recorded, divided partwise, on the disk, all the information as to the fact of division is assimilated at the logical filesystem 
35 level. Therefore, as shown in Fig. 40, there is no need to give concern as to the fact of division in the representation of 
<Address LUT>. 

[0333] Most of the addresses in <Address LUT> are given by relative address representations based on the front of 
the EUS, and even when an EUS has been recorded, divided partwise, on the disk, the management by <Address 
LUT> is made on the assumption that the EUS is arranged continuously. 
40 [0334] The access length (the number of logical blocks) designated for disk access can be determined by calculation. 
For example, the size of one EU or VU can be determined simply by its difference from the start address of the next 
EU or VU. 

[0335] The relative address system based on the start of EUS in <Address LUT> needs to be modified when some 
front part of the EUS is deleted. Specifically, <Address LUT> should be renewed by subtracting the number of deleted 
45 logical blocks from each piece of information represented in the relative address system based on the start of EUS in 
<Address LUT>. 

[0336] In order to save the job of renewing all the addresses in the management information, the <Address Offset> 
value (Figs. 1 1 , 21 and 38) for storing the number of deleted blocks is prepared to deal with the case when an arbitrary 
number of EUs have been deleted from the front of the EUS. 
so [0337] For example, as shown in Fig. 41 , if EU#0 is deleted, it is no longer necessary to renew the values of 'RLBN 
of VU', <RLBN of PRU> and 'RLBN of EU' in <Address LUT> (Figs. 11 , 21 and 38) when using this <Address Offset>. 
[0338] That is, by subtracting the <Address Offset> value from the addresses in <Address LUT>, the correct values 
can be obtained. Accordingly, the relative address of a VU from the start of EUS can be determined finally by the 
following formula: 

55 

RLBN of VU' = RLBN of VU - Address Offset. 
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[0339] In order to obtain a logical block address on the disk, it is also necessary to refer to the information from the 
logical format. That is, it is necessary to combine the start address of the EUS and division information obtained from 
the management information of the logical format, with the address information finally obtained from <Address LUT>. 
[0340] Next, the method of implementing playback from a target frame will be described. Here, description will be 

5 made of a playback method where a target frame is designated first so as to start playback from the designated video 
frame. As stated above, an arbitrary section from the EUS is selected by each scene of the user programs. 
[0341] For this selection, the ID of the <EUS lnformation> desired to be referred to and the start point and end point 
in the EUS managed by the <EUS lnformation> should be designated by the time information in PT format. From the 
PT of the video frame designated as the start point, the start address of the VU including the designated frame is 

10 determined. This address is the start point on the disk to which access should be made. 

[0342] Actual disk access is controlled by totalizing the address information of all the VUs to be accessed and the 
information obtained from the logical filesystem. The control is repeated until the VU including the video frame desig- 
nated by the end PT is reached, thus making it possible to read out the data desired to be reproduced from the disk. 
[0343] In practice, the video frame from which the start of playback is wanted is not always the front frame of the 

15 VU, but as stated already, the first reference picture in the VU should be transferred to the decoder, under the require- 
ment of the MPEG characteristics. 

[0344] Therefore, the data from the front of the VU is transferred to the decoder, and of the decoded data, display 
should be started at the point of time when the designated start PT coincides the PTS of the decoded frame. Similarly, 
for the end point, the video frames after the end PT in the last VU should be controlled so as not to be displayed. 

20 [0345] Next, a special playback method using arbitrary reference pictures will be described. <Address LUT> presents, 
in addition to the start address of a VU, the end addresses of l-pictures and P-pictures in the VU. As shown in Fig. 42, 
the address mentioned here is represented by the number of logical blocks from the front of the VU. 
[0346] The end addresses of l-pictures and P-pictures are the information needed to implement a special playback 
using l-pictures and P-pictures only. The reason the information as to start address of each picture is not given is as 

25 follows. That is, in order to decode a P-picture, it is necessary to obtain the previous l-picture or P-picture. Therefore, 
when playback is desired to start from an arbitrary P-picture, it is impossible to decode that P-picture without reading 
a multiple number of reference pictures from the disk. 

[0347] In this case, it is faster than selective reading of the reference picture parts only such as l-pictures or P- 
pictures (a seek is needed for every time a selection is made) if data is read continuously from the front of the VU to 
30 the end of the target P-picture while discarding unnecessary B-pictures which constitute a lesser amount of data com- 
pared to the other l-pictures and P-pictures. 

[0348] The each end address functions as the information for obtaining the amount of data in which data should be 
continuously read from the disk beforehand when special playback using l-pictures and P-pictures only is performed 
in such a mannerthat some of the first l-pictures and P-frames are displayed and then the playbackjumps to the next VU . 

35 [0349] In connection with this, when a semiconductor memory having high-speed access performance is adopted 
as the recording medium or when a disk drive having markedly high-access performance is used, high enough a 
performance can be achieved to selectively read the reference pictures. In this case the start addresses will be also 
given as the positional information of the reference pictures, in addition to their end addresses. 
[0350] Imparting the start and end addresses of the reference pictures as the positional information makes it possible 

40 to selectively read data of the reference pictures only, from the recording medium. Alternatively, it is also possible to 
put the positional information of all the video frames under control. 

[0351] The positional information in this case should be represented by the record start position of each video frame 
on the disk. The amount of data of each frame or the end address can be calculated simply using the difference from 
the start address of the next frame. 
45 [0352] As the information to be referred to when an access is actually made by a user program, <Closed GOP> and 
<Non Contiguous Point> information are provided in <VU Status> (Figs. 11 , 21 and 32). 

[0353] <Closed GOP> is the information which manages whether the first GOP in the VU is a closed GOP. Usually, 
the video frames in a GOP are created using only the data of the video frames in the GOP, but in the MEPG standard, 
use of the information from the video frames belonging to the previous GOP is allowed for encoding. 
50 [0354] A GOP being a closed GOP means that all the frames in that GOP have been encoded based on only the 
data therein. In contrast, a GOP being not a closed GOP means that some frames of the observed GOP have been 
encoded using the information from the previous GOP. 

[0355] The first GOP in the VU to which an access is about to be made being not a closed GOP means that the 
video of some of the first frames in that GOP cannot be decoded and reproduced correctly. An advance notice of this 
55 fact is able to prevent incorrect reproduction; for example, when the GOP is not a closed GOP, an access to the previous 
VU makes it possible to make correct reproduction of video. 

[0356] <Non Contiguous Point> information is the information that represents whether the EU being currently ob- 
served is connected to the previous EU logically and contiguously on the disk. Because of excellency of a disk in 
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random accessibility, a series of information may not necessarily arranged as contiguous data on the disk. 
[0357] Since an EUS on the disk is recorded continuously in EU units. <Non Contiguous Point> information that 
represents whether the EU being currently observed is contiguously arranged to the previous EU should be given. 
[0358] Since the addresses handled in <Address LUT> are mainly relative addresses from the start of the EUS as 

5 already stated, only the start addresses of EUs will not be able to give knowledge of whether the EUS is divided or not 
on the disk. For example, examination of whether the EUS is arranged continuously can be computed in advance by 
a combination of the management information of <Address LUT> and the management information of the logical format. 
[0359] In the actual process, based on the EUS division information which can be obtained from the logical filesystem, 
divided points relatively viewed from the start of the EUS are known. The divided points relatively viewed from the start 

10 of the EUS and the relative addresses from the start of the EUS, obtained from <Address LUT> are compared. The 
coincident EU start addresses are understood as the divided points. 

[0360] In this way, examining whetherthe data which is about to be reproduced is distributed discontinuously on the 
disk requires a troublesome task. Use of <Non Contiguous Point> information makes it possible to know divided points 
easily without referring to the information from the logical filesystem. 
15 [0361] Advance knowledge of the layout information of the data on the disk being about to be reproduced not only 
provides the information for access but also can be used to perform control of data reading from the disk for realizing 
seamless playback, for example. 

[0362] The situation where the data being about to be read is arranged, divided partwise on the disk means occur- 
rence of seek at that divided point. Occurrence of a seek means that data cannot be read during the seek time. 
20 [0363] In order to prevent a playback break from occurring even if such a seek occurred, a shock proof memory is 
provided for temporal storage of the data read from the disk. 

[0364] Provision of the shock proof memory is able to prevent playback movie breaks against occurrence of seeks 
to some extent. However, if flow of data into the shock proof memory stops over a long period due to frequent occur- 
rences of seeks, the playback movie will break. Therefore, advance knowledge of occurrence of a seek, which is the 

25 cause of stoppage of data inflow into the shock proof memory, facilitates seamless playback control. 

[0365] For example, when a risk that the playback movie may break at the divided point is expected beforehand, the 
data at that point may and should have been stored beforehand into a memory having high-speed access performance. 
[0366] In the above way, use of <Non Contiguous Point> information makes it possible to easily grasp the location 
of each EU on the disk without using the data from the logical filesystem, and is effective in making control of reading 

30 data to which an access is to be made. 

[0367] Next, description will made of how to calculate the playback rate. Use of <Address LUT> of the present in- 
vention makes it possible to compute the playback rate of video data in advance without reading the video data from 
the disk. 

[0368] The playback rate can be calculated with respect to the presentation period of time of EU or VU. First, a 

35 method of calculating the playback rate for each EU will be described. 

[0369] As stated above, the start address of an EU can be obtained by referring to <Address LUT>. Also as stated 
already, the addresses managed by <Address LUT> are represented by the relative logical block number from the 
front of the EUS assuming that it is continuous even though the EUS is recorded, divided in parts on the disk. 
[0370] Therefore, the size of an EU currently observed can be known by subtracting the start address of the EU 

40 currently observed from the start address of the next EU. 

[0371] As already stated, one EU is comprised of VUs and a PRU, or VUs only. One VU is a management unit having 
a VU Header, original audio data and video data multiplexed therein. The PRU is an area for audio data area for post 
recording, which is reproduced in synchronization with the video data in the EU. 

[0372] Since the original audio data and the audio data for post recording employ a fixed rate, the sizes of these 
45 areas can be uniquely determined from the presentation period of one EU, for example. 

[0373] Therefore, it is possible to obtain the amount of video data contained in one EU by subtracting the amount of 

data of the PRU, if the PRU presents (this can be obtained also form the management information <EUS Information^, 

the amount of the original audio data and the size of management information of fixed lengths of data such as <EU 

Header> or <VU Header> from the size of data of the EU being observed. 
50 [0374] Once the amount of the video data contained in one EU is known, the playback rate of the video data of the 

EU being observed can be calculated by dividing the amount of the video data by the presentation period of one EU. 

[0375] Next, a method of calculating the playback rate for each VU will be described. As stated above, the start 

address of a VU can be obtained by referring to <Address LUT>. 

[0376] Also as stated already, the addresses managed by <Address LUT> are represented by the relative logical 
55 block number from the front of the EUS assuming that it is continuous even though the same EUS is recorded in parts 
on the disk. 

[0377] Therefore, the size of a VU currently observed can be known by subtracting the start address of the VU 
currently observed from the start address of the next VU . Here, it should be noted that because the first VU in the EU 
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has a PRU at the front or halfway, the amount of data of the VU cannot be calculated simply with the start addresses 
of this and the next VUs. 

[0378] As already stated, one VU is a management unit having <VU Header>, original audio data and video data 
multiplexed therein. Since the original audio data employs a fixed rate, the size of this area can be uniquely determined 

5 from the presentation period of one VU, for example. 

[0379] Therefore, it is possible to obtain the amount of video data contained in one VU by subtracting the amount of 
the original audio data and the size of management information of fixed lengths of data such as <VU Header> from 
the size of data of the VU being observed. Here, when the start address of the first VU in the EU is referred to, the 
amount of data of the PRU needs to be taken into account. 

10 [0380] Once the amount of the video data contained in one VU is known, the playback rate of the video data of the 
VU being observed can be calculated by dividing the amount of the video data by the presentation period of one VU. 
[0381 ] The thus calculated playback rate of video data for each EU or for each VU can be displayed in real-time on 
the playback screen such as a monitor, for example, as the user information, without providing special hardware. 
[0382] Further, since the playback rate of the video data being about to be reproduced can be known beforehand 

15 without reading any MPEG data recorded on the disk, this configuration is useful in, for example, achieving seamless 
playback control as mentioned before. 

[0383] The playback rate for each VU or for each EU gives the information representing the amount of data read out 
from the disk for reproducing the data of the presentation period of one VU or EU. Therefore, it becomes possible to 
obtain advance knowledge of how the data will be read into the aforementioned shock proof memory in progress of 

20 calculating the playback time. 

[0384] For example, when the playback rate is low, the amount of data on the disk corresponding to a unit of playback 
time is low. Therefore, there is a wide margin for data reading from the disk. In contrast, when the playback rate is 
high, the amount of data on the disk corresponding to the same unit of playback time is high. Therefore, there is a 
lesser margin for data reading from the disk. 

25 [0385] In this way, if the playback rate of the data being about to be reproduced can be known beforehand, it is 
possible to grasp the status of the shock proof memory in advance. 

[0386] Thus, it is possible to grasp the state of the shock proof memory and sections that can allow greater time for 
disk access and sections that allow minimal time for disk access, in advance. Therefore, this feature lends itself to 
scheduling of disk access control, in such a manner that, for example, the period for a section which can afford much 
30 time for disk access, is adapted to be allotted to read into a semiconductor memory the data for the point at which 
seamless playback might break, interpreted from the aforementioned <Non Contiguous Point>. 
[0387] Next, the method of creating management information will be described. Here, an example of a method of 
creating the management information of <Address LUT> will be described. Fig.43 shows an overall system configu- 
ration of this embodiment. 

35 [0388] In the drawing, an MPEG encoder/decoder 1 encodes and decodes MPEG data. An AV system unit 2, in its 
recording mode, multiplexes the MPEG data from the MPEG encoder and audio data obtained so as to shape the data 
into a stream to be recorded onto the disk and adds header and other information. This unit, in its playback mode, 
extracts the video and audio data from the read out stream from the disk, designated at 7 and transfers it to the MPEG 
decoder. 

40 [0389] A shock proof memory 3 temporarily stores the stream therein and also performs processes such as ECC 
processing, sector codec and the like. This shock proof memory 3, by its temporal storage of data, also has the function 
of preventing against stoppage of data even when data cannot be actually read out or written in due to the disk drive 
performing seek or other reasons. 

[0390] A disk controller 4 governs servo control and disk access. A host microcomputer 5 controls the whole system 
45 by issuing control signals to various processors and receiving signals therefrom. 

[0391] When MPEG data is recorded as an EUS, a new <Address LUT> should be created. First, the video data to 
be recorded is encoded by the MPEG encoder. Similarly, the audio data is encoded by an audio encoder at the same 
time. 

[0392] The data thus encoded is sent to AV system unit 2, where the data is multiplexed in the M PEG stream format 
50 as stated above and added with header information and the like. Since in this AV system unit 2 multiplexing and addition 
of headers are implemented, AV system unit 2 should get and hold the positional information of the VU front points 
and reference pictures in VUs. 

[0393] The management information of these pieces of positional information is transferred from AV system unit 2 
to host microcomputer 5 for making the whole processing control and is sequentially held therein. The stream multi- 
55 plexed through AV system unit 2 is temporarily stored into shock proof memory 3, where the data is exchanged with 
a signal processing unit 6, so that the data is subjected to ECC processing, sector codec and other processes, to 
thereby complete preparation for recording onto disk 7. 

[0394] The thus prepared data for recording is recorded onto disk 7 at an address designated by host PC 5, through 
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disk controller 4 at a certain timing. As stated above, host microcomputer 5 grasps the positional information of the 
front end of each VU, the reference pictures in the VU and PRU and creates information for constructing <Address 
LUT> based on these pieces of information. 

[0395] <Non Contiguous Point> information should be created taking into account the held information of the stream 

5 and the addresses at which the stream of data is actually recorded onto the disk. Since the information as to post 
recording and the information as to closed GOP are determined beforehand on the host side, the determined values 
by the host should be recorded as they are as the management information of <Address LUT>. 
[0396] Next, the disk device will be described. As stated already, <Address LUT> created for every recording of an 
EUS has to be recorded onto the recording medium at a certain timing. The management information can be recorded 

10 at various sites on the recording medium. 

[0397] As shown in Fig. 44, the data area and the management information area can be separated by writing man- 
agement information into a predetermined management information area on the recording medium. For example, if 
management information is recorded together, it is possible to efficiently read data from the disk in a short period of 
time when amultiple number of EUSs need to be accessed successively. 

15 [0398] Further, there is a high possibility that the management information of this kind is updated frequently and 
complicatedly. Therefore, if such pieces of management information are scattered on the disk, it takes much time for 
disk access, resulting in lowered system response. Moreover, since no file of management information is formed in 
the data area, there is the advantage that the data is very likely to be arranged contiguously in the data area. 
[0399] When each piece of management information is written in immediately before the stream of an associated 

20 EUS recorded in the data area in the recording medium as shown in Fig. 45, the management file of the EUS to be 
accessed is located in proximity to the real data. When an EUS is copied to another recording medium, which is 
connected via network, for example, the copy can be achieved by simple file copy because the real body of the EUS 
is managed as a file by the logical filesystem. 

[0400] When the management information such as <Address LUT> for allowing for an access to an arbitrary frame 
25 in the EUS is arranged adjacent to the EUS, the management information can also be copied easily. Further, since the 

management information for each EUS is scattered on the disk, it is possible to reduce the risk of the management 

information being lost, compared to the case where the management information is recorded en masse at a site. 

[0401] Management information may be recorded in a multiplexing manner in the stream of EUSs recorded in the 

data area of the recording medium as shown in Fig. 46. In this case, when, for example, the disk also has a management 
30 area holding the same information therein, if the management information has been lost due to some accident, the 

management information multiplexed in the stream makes it possible to back up the management information. Thus, 

this configuration has the advantage of increased safety. 

[0402] Here, Fig. 46 shows an example where management information is stuffed into EU headers multiplexed in the 
stream. 

35 [0403] Further, as shown in Fig. 47, management information may be recorded into the non-volatile semiconductor 
memory, for example, provided in a disk device for reproducing the recording medium or another recording medium 
other than the recording medium with real data recorded therein, instead of being recorded into the recording medium 
itself that is recorded with real data. 

[0404] For example, it is possible to consider a configuration where real data is recorded onto a removable disk while 
40 management information is recorded into a semiconductor memory or a hard disk in the disk device. Alternatively, in 

a removable disk, a separate non-volatile semiconductor memory may be provided in the disk cartridge so that the 

management information is recorded into the semiconductor memory. In this case, since the management information 

which is read out and written in frequently is stored in the semiconductor memory which allows for high-speed access, 

this configuration has the advantage that the system response will be improved. 
45 [0405] As has been described, the management information can be recorded at different sites in various ways, each 

having different advantages. Of course, the management information may be written at multiple sites instead of being 

recorded at one site. 

[0406] For example, when using the combination of the technique of recording management information at the pre- 
determined management area and the technique of embedding the management information in the stream itself, the 
50 management information recorded in the predetermined management area is used under usual conditions, and in case 
the management information has been lost, the lost management information can be reconstructed based on the 
management information embedded in the stream. 

[The second embodiment] 

55 

[0407] The description heretofore has been made as to the embodiment in which the MPEG stream includes PRUs, 
i.e., data areas for audio dubbing. Now, description will be made of an embodiment of <Address LUT> for a case where 
PRUs, i.e., data areas for audio dubbing, are provided in an extra file other than that for the MPEG stream over which 
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audio dubbing is made or data of audio dubbing are recorded in an extra area. The aforementioned short titles are 
also used herein. 

[0408] Referring first to Fig. 48, the MPEG stream composition in this embodiment will be described. As shown in 
Fig. 48, one EUS is composed of one or more EUs and corresponds to the unit from start of recording to the stop of 
5 recording or to a pause of recording. The MPEG data managed by one EUS has to be added with a sequence of time 
stamp. 

[0409] Here, EU is the minimum unit for destructive edit. Destructive edit means an act of editing accompanied by 
a move or deletion on the disk. The minimum unit of destructive edit means that move and deletion on the disk can be 
done only EU by EU. 

10 [0410] If some EUs are deleted from the middle of one EUS by destructive edit, the time stamp of the MPEG stream 
presents discontinuity, so that the EUS needs to be divided. 

[0411] EU is composed of one or more VUs and has to be recorded continuously on the disk. The number of VUs 
in one EU is determined depending on the unit based on which post recording (audio dubbing) is performed. That is, 
the number is determined depending on the playback rate of data and mechanical performance for achieving real-time 

15 audio dubbing, i.e., audio dubbing while the video data over which audio dubbing is made is being played back. 

[0412] VU is a unit comprised of <VU Header>, one or greater number of GOPs of video data, associated audio 
data. The presentation time of all the EUs and that of all the VUs in one EUS are set constant. The presentation time 
of VU corresponds to the playback time of video data managed by a single VU. Similarly, the presentation time of EU 
indicates the playback time of video data managed by a single EU. 

20 [0413] The EUS is divided into blocks having a fixed length of 2048 bytes. One block is stored into one logical block 
on the disk. Principally, one block is constructed of one packet. The packet used here conforms to PES Packet defined 
by ISO/IEC 1 381 8-1 , and packets of this type should be recorded onto the disk. 

[0414] In the drawing, VU is composed of a VH BLK, A BLKs and V BLKs. VH BLK stores a packet of the header 
information as to the VU. A BLK stores an audio packet defined by ISO/IEC 13818-3. V BLK stores a packet of video 

25 data defined by ISO/IEC 13818-2. The thus configured EUS is managed as one file on the disk. 

[0415] On the other hand, in the stream configuration shown in Fig. 49, a post recording sequence PRS (to be ab- 
breviated as 'PRS' hereinbelow) is composed of a multiple number of PRUs. One PRU serves as a receptacle for 
recording audio dubbing data corresponding to one EU in an EUS. PRU is composed of a PH BLK, A BLKs, P BLKs. 
PH BLK stores a packet of the header information as to the PRU. A BLK stores an audio packet defined by ISO/IEC 

30 13818-3. P BLK stores a padding packet defined by ISO/IEC 13818-1 . Since a PRU is an area for post recording data 
to be reproduced in synchronization with the video data in the associated EU, it should have at least an area size 
capable of recording data equivalent to the presentation time of video data in the EU. The thus configured PRS is 
managed as one file on the disk. 

[0416] The PRS file in its initial state has no PRU recorded therein. That is, PRUs are added one by one to the PRS 
35 file in the course of audio dubbing in EU units. Therefore, the recorded order of the PRUs in the PRS file is the order 
in which audio dubbing has been performed, hence does not always coincide with the sequential order of EUs in the 
EUS. 

[0417] When using a disk with an MPEG stream recorded thereon playback from an arbitrary frame is started or a 
special playback such as reproducing arbitrarily selected frames is implemented, it is impossible as stated above to 
40 locate the recorded position of an arbitrary frame on the disk by calculation or other method because the amounts of 
data of individual frames of MPEG data recorded on the disk are different from one another. This is why management 
information, i.e., <Address LUT> for making an access to an arbitrary frame is needed, so the content will be described 
next. 

[0418] In this embodiment, post recording indicates audio dubbing, which is performed by post recording sound only 
45 over the original data already recorded. PRUs indicate areas in which post recording data will be recorded when audio 

dubbing is implemented, and are recorded into a separate file from the EUS file, namely a PRS file. 

[0419] Next, description will be made of under what situation <Address LUT> should be used. A section of MPEG 

data recorded by the user from its recording start to recording stop or to pause is defined as one EUS. 

[0420] It is assumed that actual MPEG data is recorded as files by EUS units of video and original audio data, using 
50 a logical filesystem which manages the positional information of data on the disk by file names while audio dubbing 

data is managed as files, i.e., PRS files, separately from EUSs.This configuration is shown in Fig. 50. In this example, 

EUS#0 and EUS#1 are managed as file names of FDAV0000.EUS and FDAV0001 .EUS, respectively, and PRS files 

(audio dubbing files) corresponding to EUS#0and EUS#1 are managed as file names of FDAV0000.PRS and 

FDAV0001 .PRS, by the logical filesystem. 
55 [0421] To manage EUS data in EUS units, management information called <EUS lnformation> is created. That is, 

if the user recorded multiple scenes, each corresponding to data from recording start to recording stop, an equal number 

of <EUS lnformation> is created. 

[0422] One example of <EUS lnformation> is shown in Fig. 51 . <EUS lnformation> is the information to manage an 
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EUS recorded on the disk. As shown in Fig. 51 , <EUS lnformation> has its ID for its distinction, size, title information, 
creation date and updated date of the EUS, text information, thumbnail information for managing a representative 
thumbnail of the EUS, <Data File ID> and <PRS File ID> for identifying the EUS of the MPEG stream data and the 
RPS file as an audio dubbing data file, managed by the logical filesystem, <Data File Size> and <PRS Data Size> 
5 representing the data sizes of the EUS and PRS, property information such as EUS, video, audio, camera, post re- 
cording, source, copyright, still picture, etc. 

[0423] The EUS information also has reference information which reveals the programs which refer to the EUS 
managed thereby. Further, as the management information of importance, <Start PT>, <End PT>, <Post Recording 
Unit Size> and <Address LUT> can be mentioned. 
10 [0424] Recorded into <Start PT> and <End PT> are PTS values, attached to the data stream itself at the first and 
last display frames in the EUS managed by this <EUS Information;^ or the corresponding PTS values, converted in 
PT format. Since one EUS always handles a piece of video data having sequential time stamp, the total presentation 
time of the EUS can be calculated by subtracting <Start PT> from <End PT>, for example. 

[0425] <Post Recording Unit Size> is the information representing the size of the PRU. It should be noted that the 
15 size of each PRU within the same PRS is constant. <Address LUT> is the management information which provides 
where on the disk access should be made to for an arbitrary frame of the MPEG data and corresponding audio dubbing 
data recorded on the disk. In the above way, based on <EUS Informations it is possible to obtain the information as 
to an EUS and PRS files recorded as files on the disk. 

[0426] When the MPEG data recorded by the user is played back serially from the front in the order recorded, it is 
20 possible to perform playback without the aforementioned <Address LUT>. However, if, taking advantage of random 
accessibility of the disk, for example, the user tries to select an arbitrary number of arbitrary sections from EUSs which 
are the original data in its recorded state and reproduce in an arbitrary order, the management <Address LUT> will be 
needed. 

[0427] Next, a method of determining the start addresses of PRUs and VUs in the aforementioned MPEG stream 
25 by calculation will be described herein below. 

[0428] In reproducing an MPEG stream, there is a possibility that the user may have implemented post recording 
(audio dubbing). Therefore, if there exist PRUs corresponding EUs, this should be checked using aftermentioned <PRU 
Status> or <PR Existence> in <VU Status>. 

[0429] <PR Existence> in <PRU Status> of <PRU lnformation> is the management information showing whether 
30 there exists a PRU corresponding to each EU in the PRS file. <PR Existence> in <VU Status> of <VU lnformation> is 
the management information showing whether there exists post recording data corresponding to the managed VU. 
[0430] When a piece of post recording data exists and needs to be reproduced, it is necessary to read the corre- 
sponding PRU (audio dubbing data) beforehand prior to access to the target EU, then reproduce the read, PRU in 
synchronization with the video when the video data in the EU is played back. 
35 [0431] In this way, use of the <PR Existence> information makes it possible to grasp beforehand whether or not 
there are corresponding PRUs in the PRS file and whether or not post recording has been made. 
[0432] Fig. 52 shows an example of management information of <Address LUT>. The definitions will be described 
consecutively hereinbelow. Figs. 53 through 57 show the details of the management information in Fig. 52. 
[0433] In Fig. 53, <Address Offset> stores an offset value for creating relative logical block numbers (RLBN) managed 
40 by the <address LUT>, in Unit 32 format. When an arbitrary number of EUs have been deleted from the front part of 
the EUS, the number of the deleted logical blocks is set into this field. 

[0434] Accordingly, when referring to a relative logical block number (RLBN of VU) for managing the start address 
of a VU handled in <Address LUT>, it is necessary to subtract this <Address Offset> from that value. The initial value 
has to be set at 0. 

45 [0435] <PB Time of EU> represents the set presentation time of each EU in the EUS managed by the oddress 
LUT>. The set presentation time is the playback time of the video data in one EU and is constant within the same EUS, 
except the last EU in the EUS. 

[0436] <PB Time of EU> should be recorded in PT Format. Here, <PB Time of EU> should be an integer multiple of 
the difference in PTS, represented in PT Format, between adjacent video frames in the MPEG stream, i.e., the PTS 
50 corresponding to the presentation time per frame. 

[0437] <PB Time of VU> represents the set presentation time of each VU in the EUS managed by the oddress 
LUT>. The set presentation time is the playback time of the video data in one VU and is constant within the same EUS, 
except the last VU in the EUS. 

[0438] <PB Time of VU> should be recorded in PT Format. Here, <PB Time of VU> should be an integer multiple of 
55 the difference in PTS, represented in PT Format, between adjacent video frames in the MPEG stream, i.e., the PTS 
corresponding to the presentation time per frame. 

[0439] <Number of PRU lnformation> is the number of EUs existing in the EUS managed by the oddress LUT>, 
recorded in Unit 32 format. Since each <PRU I nformation> corresponds to one EU. If there exists no PRU in the stream 
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configuration, this field should be always set at 0. 

[0440] <Number of VU lnformation> is the number of VUs existing in the EUS managed by the <Address LUT>, 
recorded in Unit 32 format. 

[0441] <PRU lnformation> manages the information as to the PRU corresponding to each EU in the BUS, in the 
5 manner as shown in Fig. 54. When there is no PRU existing for the BUS, <Number of PRU lnformation> is recorded 
with 0 and no record is written into <PRU Informations If even one PRU corresponding to an EU in the EUS exists, 
each of the EUs should have one <PRU lnformation> of their own. 

[0442] <RLBN of PRU> represents the start address on the disk of the PRU managed by this <PRU Informations 
Here, the address is represented by the relative logical block number from the front of the PRU file. <RLBN of PRU> 
10 should be recorded in Unit24 format. <PRU Status> manages the state of the PRU managed by this <PRU Informations 
in the manner as shown in Fig.55. 

[0443] <PR Existence> (BitO) is recorded with '1 1 when the PRU corresponding to this PRU Information exists in the 
PRS file, and is recorded with '0' when no PRU exists. 

[0444] <VU lnformation> (Fig. 53) manages the information as to each VU in the EUS, in the manner as shown in 
15 Fig. 56(a) or Fig. 56(b). It should be noted that in Fig. 56(a) the positional information of the video frames managed within 
the VU is given as either the start address or end address while in Fig. 56(b) the positional information is given as both 
the start address and the end address. 

[0445] <RLBN of VU> represents the start address on the disk of the VU managed by this <VU Informations This 
address is represented by the relative logical block number from the front of the EUS file. <RLBN of VU> should be 
20 recorded in Unit 24 format. 

[0446] <VU Status> manages the state of the VU managed by this <VU lnformation> in the manner as shown in Fig. 
57(a) or Fig.57(b). Fig. 57(a) shows a case where <Non Contiguous Point> information is defined and Fig. 57(b) shows 
a case where <Non Contiguous Point> information is not defined. 

[0447] <PR Existence> (BitO) is recorded with '1' when post recording data corresponding to the VU managed by 
25 this <VU lnformation> is present and is recorded with '0' when no post recording data is present. If there is no PRU 

corresponding to the EU to which this VU belongs, this field should be always recorded with '0'. 

[0448] <Closed GOP> (Bit1 ) manages whether the first GOP in the VU is a closed GOP. If the GOP is a closed one, 

this field is recorded with '1 '. Otherwise, it is recorded with '0'. When the GOP is not a closed one, there is a possibility 

that some of the first frames of video cannot be decoded without information of the previous GOP. 
30 [0449] <Non Contiguous Point> (Bit2) (Fig. 57(b)) manages whether the EU to which the VU managed by this <VU 

lnformation> belongs is arranged on the disk logically and contiguously with the previous EU. When they are arranged 

contiguously, this field is recorded with '0'. When they are not arranged contiguously, the field is recorded with '1 '. 

[0450] <Number of IP Pictures> (Fig. 56) records the number of the positional information of l-pictures and P-pictures 

in the video data to be managed by this <VU Information^ in Unit8 format. 
35 [0451] <End RLBN of IP Pictures> (Fig. 56(a)) manages the end addresses on the disk of the l-pictures and P-pictures 

in the VU managed by this <VU Informations The address herein is represented by the relative logical block number 

from the front of the VU. 

[0452] As the first entry the address information as to the first l-picture in the VU should be stored. As the second 
entry and downward, the address information as to l-pictures and/or P-pictures should be stored in Unitl 6 format. 

40 [0453] In connection with this, when a semiconductor memory having high-speed access performance is adopted 
as the recording medium or when a disk drive having markedly high-access performance is used, the start addresses 
should be also given as the positional information of the reference pictures, in addition to their end addresses. In this 
case, the field name of this item is renamed as <RLBN of IP Pictures> and both the start address and end address 
should be recorded serially in Unitl 6 format. 

45 [0454] It is also possible to put the positional information of all the video frames under control, instead of the addresses 
of the reference pictures only. The positional information in this case should be represented by the record start position 
of each video frame on the disk. The amount of data of each frame and the end address can be calculated simply 
using the difference from the start address of the next frame. 
[0455] All the above is the management information for <Address LUTs 

50 [0456] Next, specific usage of these pieces of management information will be described with reference to Figs. 58 
and 59. 

[0457] First, description will be made of how to calculate the start address of the VU including a target frame. When 
playback is desired to be started from a frame corresponding to an arbitrary PT in an EUS, the starting position on the 
disk of the VU including that frame should be determined based on <Address LUTs 
55 [0458] The basic processing sequence for this will be as follows. Fig. 58 shows this case. 

(1 ) Relative PT (RPT) is calculated by subtracting <Start PT> (Figs. 51 -58) corresponding to the first display frame 
in the EUS from the target PT. <Start PT> is the PTS value, attached to the MPEG stream at the first display frame 
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in the EUS, or the corresponding PTS value, converted in PT format. 

RPT = PT - Start PT 

5 

As stated above, since the information as to the start point and end point, which is designated from each user 
program so as select an arbitrary section, is represented by absolute PT values, attached to the stream or corre- 
sponding values, subtraction of <Start PT> from the values will provide relative time information from the front of 
the EUS. 

10 Here, the fact that absolute time information is used in user programs means that if, for example, some part 

in the front part of the EUS was deleted, there is no need to renew the start point and end point information of all 
the user programs which refer to this EUS as the reference information as long as <Start PT> in <EUS lnformation> 
(Fig.51) is modified, thus making it possible to reduce the process load. 

(2) <VU Information Number> (Fig. 52) of the VU including the frame from which the start of playback is desired is 
15 obtained by dividing the relative PT (RPT) by the set presentation time (<PB Time of VU> (Figs. 52 and 58) of each 

VU in the EUS. In Fig.58 this value is VU#7. 

VU Info Num = ip(RPT/PB Time of VU), 

20 

where ip(n) is a function that produces the maximum integer not greater than n. 

(3) From the obtained <VU Information Number>, the start address of the VU including the target frame is obtained 
as the relative logical block number 'RLBN of VU" from the front of EUS. 

RLBN of VU 1 = RLBN of VU(VU Info Num), 

where expression 'RLBN of VU(n)' represents the value of <RLBN of VU> of the nth <VU Informations 
[0459] In the above way, the start address of the VU including a target frame can be determined by simple calculation 
30 using <Address LUT>, instead of searching or other operations. 

[0460] Next, description will be made of how to calculate the start address of the PRU corresponding to the EU 
including a target frame. The basic sequence of calculating the start address of the PRU corresponding to the EU 
including a target frame will be as follows. Fig. 59 shows this situation. 

[0461] Thefrontmost end of the PRU is a point which needs to be accessed to when post recording data correspond- 
35 ing to the target frame is present. 

(1) Relative PT is calculated by subtracting <Start PT> corresponding to the first display frame in the EUS from 
the target PT. 

40 

RPT = PT - Start PT 

(2) The number of the EU including the frame from which the start of playback is desired is obtained by dividing 
the relative PT (RPT) by the set presentation time (<PB Time of EU> of each EU in the EUS. Since each EU 

45 corresponds to one <PRU Informations this EU number directly represents <PRU Information Number>. In Fig. 

59, this value is PRU info#1 . 

PRU Info Num = ip(RPT/PB Time of EU), 

50 

where ip(n) is a function that produces the maximum integer not greater than n. 

(3) From the obtained <PRU Information Number>, the start address of the PRU corresponding to the EU including 
the target frame is obtained as the relative logical block number 'RLBN of PRU 1 ' from the front of the PRS file. 

RLBN of PRU' = RLBN of PRU(PRU Info Num). 
[0462] Here, <PR Status> in <PRU lnformation> being '0' means that no corresponding PRU exists in the PRS file. 
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[0463] In the above way, similarly to the way of determining the VU start address, the start address of the PRU to 
be reproduced in synchronization with the VU including a target frame can be determined by simple calculation using 
<Address LUT>, instead of searching or other operations. Therefore, if for example, a particular PRU is read out from 
the disk, the amount of data equivalent to the size of the PRU managed by <EUS lnformation> should be read out 

5 from the determined start address of the PRU. 

[0464] Now, the relationship between arbitrary EUs in an EUS file and PRUs in a PRU file will be described involving 
<Address LUT>, with reference to Fig. 60. In the example of this drawing, in an EUS file of an MPEG data stream from 
the start of recording to the end of recording or pause, one EU is composed of fourVUs. <PRU lnformation> in <Address 
LUT> is created for each EU. Therefore, a corresponding number of pieces of <PRU lnformation> exist as the number 

10 of EUs in the EUS file, arranged in the order from the first EU in the EUS. <PRU lnformation> corresponding to each 
EU has apiece of information <PRU Status> that represents whether there is a corresponding PRU in the PRS file. In 
the example illustrated, PRU lnformation#4 and #5 does not exist, or no PRUs corresponding to EU#4 and EU#5 exist 
in the PRS file. PRUs corresponding to EU#1 to #3, i.e., PRU information #1 to #3, are recorded as PRUs#0 to #2 in 
the PRS file. PRU Information #0, or PRU corresponding to EU#0 is recorded as PRU#3 in the PRS file. In this way, 

15 PRUs are added to the PRS file in the order recorded, so that PRUs are not necessarily arranged in the same order 
as EUs. 

[0465] When audio dubbing data is reproduced in synchronization with the video data of the EUS of the above 
structure, prior to reading each EU from the front of EUS, data of the corresponding PRU is read out from the disk. 
Subsequently, the EU data is read out so that the video data is reproduced whilst taking synchronism with the audio 
20 dubbing data already read. In this way, these units of data are read alternately in such a manner that PRUs and EUs 
are read one after another. 

[0466] As already described, EUSs and PRSs are managed as files using the logical filesystem. Even when a certain 
EUS or PRS is recorded, divided partwise, on the disk, all the information as to the fact of division is assimilated at the 
logical filesystem level. Therefore, as shown in Figs. 61 and 62, there is no need to give concern as to the fact of division 

25 in the representation of < Address LUT>. 

[0467] <RLBN of VU> and <RLBN of PRU> in <Address LUT> (Fig. 52) are given by relative address representations 
based on the front of the EUS or PRS, and even when an EUS or PRS has been recorded, divided partwise, on the 
disk, the management by <Address LUT> is made on the assumption that the EUS or PRS is arranged continuously. 
[0468] The access length (the number of logical blocks) designated for disk access can be determined by calculation. 

30 For example, the size of one EU or VU can be determined simply by the difference from the start address of the next 
EU or VU. The size of PRU is constant within the same EUS. 

[0469] The relative address system based on the start of EUS in <Address LUT> needs to be modified when some 
front part of the EUS was deleted. Specifically, <Address LUT> should be renewed by subtracting the number of deleted 
logical blocks from each piece of information represented in the relative address system based on the start of the EUS 
35 in <Address LUT>. In order to save the job of renewing all the addresses in the management information, the <Address 
Offset> value (Fig. 53) for storing the number of deleted blocks is prepared to deal with the case when an arbitrary 
number of EUs have been deleted from the front of the EUS. 

[0470] For example, as shown in Fig. 63, if EU#0 is deleted, it is no longer necessary to renew the values of 'RLBN 
of VU 1 in <Address LUT> when using this <Address Offset>. 
40 [0471 ] That is, by subtracting the <Address Offset> value from the address in <Address LUT>, the correct value can 
be obtained. Accordingly, the relative address of a VU from the start of EUS can be determined finally by the following 
formula: 



RLBN of VU' = RLBN of VU - Address Offset. 

45 

[0472] In contrast, <RLBN of PRU> represented in the relative address system based on the start of the PRS file in 
<Address LUT> needs to be modified when the front part of PRS was deleted. Specifically, <Address LUT> should be 
renewed by subtracting the number of deleted PRU logical blocks from each piece of information represented in the 

50 relative address system based on the start of the PRS in <Address LUT>. However, the records in PRUs are audio 
data, hence the size of data is small compared to video data. Therefor, when an arbitrary PRU is desired to be deleted, 
update of PRU Status in PRU Information is able to produce the same effect as the delete of the PRU, without actual 
modification of the PRS file. Further, when, for example, audio dubbing data already recorded is discarded and replaced 
with new audio dubbing, renewal of audio dubbing data can be made by extracting from PRU Information a piece of 

55 pru Information corresponding to the EU over which audio dubbing will be made and recording audio dubbing on the 
PRU at the position designated at <RLBN of PRU>. 

[0473] In the second embodiment, an embodiment of <Address LUT> for a case where PRUs, i.e., data areas for 
audio dubbing, are recorded as an extra file or extra area otherthan thatforthe MPEG stream over which audio dubbing 
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is made, has been described in combination with part of the first embodiment, but modifications other than the data 
area for audio dubbing described in the first embodiment can be added appropriately also in this embodiment. 
[0474] As has been described, according to the first aspect of the present invention, according to the first aspect of 
the present invention, in a multimedia data stream, the positional information of an arbitrary frame on the recording 
5 medium can be easily obtained without the necessity of complex calculation. 

[0475] According to the second aspect of the present invention, in a multimedia data stream, the positional information 
of a first unit of data, which is the minimum editable unit for an arbitrary frame, on the recording medium can be easily 
obtained without the necessity of complex calculation. 

[0476] According to the third aspect of the present invention, in a multimedia data stream, the positional information 
10 of a second unit of data required for access to an arbitrary frame, on the recording medium can be easily obtained 
without the necessity of complex calculation. 

[0477] Further, since positional information of second units of data which are frequently referenced is given as man- 
agement information, it is possible to refer to management information efficiently without the necessity of calculation 
of the positional information. 

15 [0478] According to the fourth aspect of the present invention, in a multimedia data stream, the positional information 
of a second unit of data required for access to an arbitrary frame on the recording medium as well as the positional 
information of a first unit of data, which is the minimum editable unit for an arbitrary frame, on the recording medium 
can be easily obtained without the necessity of complex calculation. 

[0479] According to the fifth to seventh aspects of the present invention, the positional information of post recording 
20 audio data on the recording medium, which should be reproduced in synchronization with the predetermined data, can 
be easily obtained in relation with the positional information of the individual units of data without the necessity of 
complex calculation. 

[0480] According to the eighth to tenth aspects of the present invention, the positional information of post recording 
audio data on the recording medium, which should be reproduced in synchronization with the predetermined data, can 
25 be easily obtained without the necessity of complex calculation. 

[0481] According to the eleventh aspect of the present invention, reading and writing of a plurality of pieces of man- 
agement information can be done in a short period of time. 

[0482] According to the twelfth aspect of the present invention, since the data area and the management information 
area are separated clearly, no file of management information will be created in the data area. Therefore, contiguous 

30 arrangement of data in the data area can be realized. 

[0483] According to the thirteenth aspect of the present invention, the data to be reproduced is arranged in proximity 
to the management information so that it is possible to realize an increased processing speed. 
[0484] According to the fourteenth aspect of the present invention, since the management information area is pro- 
vided for a recording medium having a higher access speed than the data recording medium, it is possible to realize 

35 a faster response. 

[0485] According to the fifteenth and sixteenth aspects of the present invention, the data recording media managing 
device, in a data recording medium in which the base unit of data is divided into the first units of data and the second 
units of data based on playback time, manages the reference position information and the first relative distance infor- 
mation in the management information area. Therefore, the managing device, using time information as the key infor- 
40 mation, can convert it into positional information by a simple process, thus making it possible to have easy access to 
an arbitrary frame in the unit of data. 

[0486] Further, even when a plurality of pieces of management information should be read or written, it is possible 
to have it done in a short period of time. Since the data area and the management information area are separated 
clearly, no file of management information will be created in the data area. Therefore, contiguous arrangement of data 
45 in the data area can be realized. 

[0487] According to the seventeenth aspect of the present invention, since the positional information of post recording 
audio data can be also obtained by a simple process, using time information as the key information, post recording 
audio data can be reproduced efficiently. 

[0488] According to the eighteenth aspect of the present invention, the data to be reproduced is arranged in proximity 
50 to the management information so that it is possible to realize an increased processing speed. 

[0489] According to the nineteenth aspect of the present invention, this configuration will not make the stream com- 
position complex, so makes it easy to access the other units of data. 

[0490] According to the twentieth aspect of the present invention, since when some front part of the multimedia 
stream has been deleted, the positional information of the deleted data is recorded as management information, i.e., 
55 the offset value, this makes it unnecessary to renew each piece of positional information in various pieces of manage- 
ment information, thus making it possible to save the editing job. 

[0491] According to the twenty-first aspect of the present invention, since the playback rate of video data in the first 
unit of data can be determined by calculation, it is possible to grasp the playback rate of data beforehand, without 
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reproducing the video data. 

[0492] According to the twenty-second aspect of the present invention, since the playback rate of video data in the 
second unit of data can be determined by calculation, it is possible to grasp the playback rate of data beforehand, 
without reproducing the video data. 
5 [0493] According to the twenty-third aspect of the present invention, since start addresses are given in a relative 
address representation, which disregards the divided arrangement of the stream on the recording medium, the data 
amount of the data managed by the first or second unit can be known from the relationship between one start address 
and the next. 

[0494] According to the twenty-fourth aspect of the present invention, since upon data reproduction it is possible to 
10 grasp whether post recording audio data should be read out in advance, this makes the process more efficient. 

[0495] According to the twenty-fifth aspect of the present invention, since upon data reproduction it is possible to 
grasp whether post recording audio data should be read out in advance for every first unit, this makes the process 
more efficient. 

[0496] According to the twenty-sixth aspect of the present invention, since upon data reproduction it is possible to 
15 grasp whether post recording audio data should be read out in advance for every second unit, this makes the process 
more efficient. 

[0497] According to the twenty-seventh aspect of the present invention, since it is possible to grasp whether the 
observed first unit is arranged logically and contiguously to the previous first unit, on the recording medium, without 
referring to the logical filesystem information, this makes the process more efficient. 
20 [0498] According to the twenty-eighth aspect of the present invention, before reproduction of a second unit of data, 
it is possible to grasp whether it is necessary to access to the previous second unit in order to perform correct repro- 
duction of the frames in the GOP within the second unit of data. 

[0499] According to the twenty-ninth aspect of the present invention, each of the second units of data is allowed to 
manage not a fixed number of frames but an arbitrary number of frames. 
25 [0500] According to the thirtieth aspect of the present invention, since the amount of data to be read from the start 
of the second unit of data to the target reference picture can be grasped in advance, this facilitates achievement of 
special playback. 

[0501] According to the thirty-first aspect of the present invention, when a recording medium having a high enough 
access performance is used, the target reference pictures can be read selectively based on the positional information 

30 from which data should be read. This feature facilitates achievement of special playback. 

[0502] According to the thirty-second aspect of the present invention, since the start addresses of all the frames are 
managed, it is possible to easily determine the amount of data of each frame from the difference from the start address 
to the next frame and to selectively read out the data of an arbitrary frame when a recording medium having a high 
enough access performance is used. Therefore, these features facilitate achievement of special playback. 

35 [0503] According to the thirty-third aspect of the present invention, since upon data reproduction it is possible to 
grasp whether post recording audio data should be read in advance, this makes the process more efficient. 

Industrial Applicability 

40 [0504] As has been described heretofore, the invention is suitable for an access position locating method and re- 
cording media managing device for locating access positions on a recording medium such as a disk or the like on 
which variable-length coded data such as MPEG data has been recorded. 



45 Claims 

1. A data access position locating method for locating access positions in a data recording medium in which a data 
sequence of a continuous recording period in a first data stream having video data is managed as a base unit of 
data, comprising the steps of: 

50 

based on presentation time information as to a specified piece of video data and reference time information 
related to reference position information of a target base unit of data, determining a relative time from the 
reference time information to the presentation time information; 

identifying a target subunit of data including the specified piece of video data by operation based on the relative 
55 time as to the specified piece of video data and playback time of a subunit of data; and 

identifying start position information of the target subunit of data from relative distance information stored 
beforehand in a management information area, 
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wherein 

the base unit of data comprises a plurality of subunits of data, each having an identical playback time within 
a single base unit of data, and 

for each of the base units of data, reference position information that is start position information of the base 
unit of data and relative distance information from the reference position information to start position information 
of each of the subunits of data in the base unit of data are stored beforehand in the management information area 
of a recording medium. 

The data access position locating method according to Claim 1 , wherein the subunit of data is a first unit of data 
that is an independently editable minimum unit of data. 

The data access position locating method according to Claim 1 , wherein the subunit of data is a second unit of 
data that is an independently reproducible minimum unit of data, and a plurality of the second units of data each 
having an identical playback time constitute one first unit of data that is an independently editable minimum unit 
of data, and a plurality of the first units of data each having an identical playback time within a single base unit of 
data. 

The data access position locating method according to Claim 3, further comprising the step of identifying start 
position information of the first unit of data, using start position information of the second units of data. 

The data access position locating method according to Claims 2 through 4, wherein the data recording medium 
has in association with the first units of data, audio data recording units for post recording for storing post recording 
audio data, which differs from the original audio data associated with video data and is recordable and reproducible 
in synchronization with the video data and the management information area has stored beforehand third relative 
distance information as the start position information of the audio data recording unit for post recording for each 
base unit of data, 

the method further comprising the step of identifying the start position information of the target audio data 
recording unit for post recording corresponding to the target first unit of data, based on the third relative distance 
information stored in the management information area. 

The data access position locating method according to Claim 5, wherein the third relative distance information is 
relative distance information from the reference position information to the start position information of the audio 
data unit for post recording. 

The data access position locating method according to Claim 5, wherein the third relative distance information is 
relative distance information from the start position information of the first unit of data to the start position information 
of the audio data unit for post recording. 

A data access position locating method for locating access position in a data recording medium in which a data 
sequence of a continuous recording period in a first data stream having video data is managed as a base unit of 
data, comprising the steps of: 

based on presentation time information as to a specified piece of video data and reference time information 
related to reference position information of a target base unit of data, determining a relative time from the 
reference time information to the presentation time information; 

identifying a target first unit of data including the specified piece of video data, by operation based on the 
relative time as to the specified piece of video data and a playback time of a first unit of data; and 
identifying start position information of a target audio data unit for post recording, corresponding to the target 
first unit of data, from third relative distance information stored beforehand in a management information area, 

wherein 

the base unit of data comprises a plurality of first units of data, each having an identical playback time within 
a single base unit of data and being an independently editable minimum unit of data, 

the data recording medium has in association with the first units of data, audio data units for post recording 
for storing post recording audio data, which differs from original audio data associated with the video data and is 
recordable and reproducible in synchronization with the video data, 

for each of the base units of data, the third relative distance information that is start position information of 
each of the audio data units for post recording is stored beforehand in the management information area of a 
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recording medium. 

9. The data access position locating method according to Claim 8, wherein the third relative distance information is 
relative distance information from reference position information representing the start position information as to 

5 the base unit of data to the start position information of the audio data unit for post recording. 

10. The data access position locating method according to Claim 8, wherein the third relative distance information is 
relative distance information from start position information of the first unit of data to the start position information 
of the audio data unit for post recording. 

10 

1 1 . The data access position locating method according to Claim 5 or 8, wherein the audio data unit for post recording 
is provided inside each first unit of data. 

12. The data access position locating method according to Claim 5 or 8, wherein the audio data unit for post recording 
15 is provided outside the base units of data. 

13. The data access position locating method according to Claim 1 or 8, wherein the management information area 
is provided inside the data recording medium. 

20 14. The data access position locating method according to Claim 1 or 8, wherein the management information area 
is provided in a recording medium outside the data recording medium. 

15. A data recording media managing device for managing a data sequence of a continuous recording period in a first 
data stream having video data as a base unit of data, comprising a controller which manages the data by the steps 
25 of: 

constructing the base unit of data with a plurality of first units of data, each being an independently editable 
minimum unit of data; 

constructing the first unit of data with a plurality of second units of data each being an independently repro- 
30 ducible minimum unit of data; 

making the first playback time for reproducing each of the first units of data identical within a single base unit 
of data and controlling the second playbacktime for reproducing each of the second units of data to be identical 
within a single first unit of data; and 

managing for each base unit of data, reference position information as the start position information of the 
35 base unit of data and first relative distance information from the reference position information to start position 

information of a first unit of data in the base unit of data, in a manner that allows them to be written in, or read 
out from, the data recording medium or the management information area arranged somewhere with respect 
to a holder of the data recording medium. 

40 16. A data recording media managing device for managing a data sequence of a continuous recording period in a first 
data stream having video data as a base unit of data, comprising a controller which manages the data by the steps 
of: 

constructing the base unit of data with a plurality of first units of data, each being an independently editable 
45 minimum unit of data; 

constructing the first unit of data with a plurality of second units of data each being an independently repro- 
ducible minimum unit of data; 

making the first playback time for reproducing each of the first units of data identical within a single base unit 
of data and controlling the second playbacktime for reproducing each of the second units of data to be identical 

50 within a single first unit of data; and 

managing for each base unit of data, the reference position information as the start position information of the 
base unit of data and second relative distance information from the reference position information to the start 
position information of a predetermined second unit of data in the base unit of data, in a manner that allows 
them to be written in, or read out from, the data recording medium or the management information area ar- 

55 ranged somewhere with respect to a holder of the data recording medium. 

17. The data recording media managing device according to Claim 15 or 16, wherein the controller constructs in the 
data recording medium an audio data unit for post recording for storing post recording audio data, which differs 
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from the original audio data associated with the video data and is recordable and reproducible in synchronization 
with the video data, and manages third relative distance information from the reference position information to the 
start position information of the audio data unit for post recording, in association with each of the first units of data, 
in a manner that allows it to be written in or read out from the management information area. 

5 

18. The data recording media managing device according to Claim 1 7, wherein the audio data unit for post recording 
is provided inside the first unit of data. 

19. The data recording media managing device according to Claim 1 7, wherein the audio data unit for post recording 
10 is created outside the base units of data. 

20. The data recording media managing device according to Claim 15 or 16, wherein the controller manages offset 
information that gives an offset value for positional information in a manner that allows it to be written in, or read 
out from the management information area. 

15 

21. The data recording media managing device according to Claim 15, wherein the controller is able to compute a 
data playback rate of the first unit of data, based on the first relative distance information and the first playback time. 

22. The data recording media managing device according to Claim 16, wherein the controller is able to compute a 
20 data playback rate of the second unit of data, based on the second relative distance information and the second 

playback time. 

23. The data recording media managing device according to Claim 1 5 or 1 6, wherein the positional information is given 
in a relative address representation which disregard any divided arrangement on the recording medium. 

25 

24. The data recording media managing device according to Claim 1 7, wherein the controller manages post recording 
presence/absence information that indicates whether the post recording audio data to be reproduced in synchro- 
nization has been stored in the audio data unit for post recording in a manner that allows it to be written in or read 
out from the management information area. 

30 

25. The data recording media managing device according to Claim 1 7, wherein the controller manages post recording 
presence/absence information that indicates whether the post recording audio data to be reproduced in synchro- 
nization with the first unit of data has been stored the an audio data unit for post recording in a manner that allows 
it to be written in or read out from the management information area. 

35 

26. The data recording media managing device according to Claim 1 7, wherein the controller manages post recording 
presence/absence information that indicates whether the post recording audio data to be reproduced in synchro- 
nization with the second unit of data has been stored in the audio data unit for post recording in a manner that 
allows it to be written in or read out from the management information area. 

40 

27. The data recording media managing device according to Claim 14 or 15, wherein the controller manages data 
contiguousness information that indicates whether the data corresponding to the first unit of data and the data 
corresponding to the subsequent first unit of data, which are continuous temporally, are arranged logically and 
contiguously on the recording medium, in a manner that allows it to be written in or read out from the management 

45 information area. 

28. The data recording media managing device according to Claim 1 5 or 1 6, wherein the controller manages informa- 
tion that indicates whether or not a GOP at the front of the second unit of data is a closed GOP, in a manner that 
allows it to be written in or read out from the management information area. 

50 

29. The data recording media managing device according to Claim 15 or 16, wherein the controller manages video 
frame information that indicates the number of video frames of MPEG data to be managed in the second unit of 
data, in a manner that allows it to be written in or read out from the management information area. 

55 30. The data recording media managing device according to Claim 1 5 or 1 6, wherein the controller manages a video 
frame of MPEG data to be managed in a second unit of data by allowing end position information that represents 
an end address of a reference picture on the recording medium to be written in or read out from the management 
information area. 



42 



EP 1 206 135 A1 



31 . The data recording media managing device according to Claim 1 5 or 1 6, wherein the controller manages reference 
picture start position information that represents a start address on the disk of a reference picture for the video 
frame of MPEG data to be managed in a second unit of data and reference picture end position information that 
represents an end address thereof, in a manner that allows them to be written in or read out from the management 
information area. 

32. The data recording media managing device according to Claim 1 5 or 1 6, wherein the controller manages a video 
frame of M PEG data to be managed in the second unit of data by allowing start position information that represents 
a start address of a reference picture on the recording medium to be written in or read out from the management 
information area. 

33. A data recording media managing device for managing a data sequence of a continuous recording period in a first 
data stream having video data as a base of data, wherein the base unit of data comprises a plurality of subunits 
of data, the device comprising a controller which manages each base unit of data in a manner that reference 
position information as start position information of the base unit of data, relative distance information of each of 
individual subunits of data, in the base unit of data from the base position information to the start position information 
of the individual subunit of data and post recording presence/absence information that indicates whether post 
recording audio data to be reproduced in synchronization has been stored in a post recording audio data unit, are 
allowed to be written in or read out from, the data recording medium, or the management information area arranged 
somewhere with respect to an indicator of the data recording medium. 
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